linux-kernel - Re: [PATCH 08/13] iscsi-target: Add CHAP Authentication support using libcrypto

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 23 Jul 2011 22:08:08 -0500
From:	Mike Christie <michaelc@...wisc.edu>
To:	linux-iscsi-target-dev@...glegroups.com
CC:	"Nicholas A. Bellinger" <nab@...ux-iscsi.org>,
	James Bottomley <James.Bottomley@...senPartnership.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	target-devel <target-devel@...r.kernel.org>,
	linux-scsi <linux-scsi@...r.kernel.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Christoph Hellwig <hch@....de>,
	Andy Grover <agrover@...hat.com>,
	Hannes Reinecke <hare@...e.de>,
	Roland Dreier <roland@...estorage.com>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH 08/13] iscsi-target: Add CHAP Authentication support	using
 libcrypto

On 07/23/2011 04:17 PM, Nicholas A. Bellinger wrote:
> 
> And, we have also seen historically how painful the split has been with
> open-iscsi, which in the end took much longer to get stable (and is
> still harder to debug) than if a proper login split was used to begin
> with.

Here is my 2 cents from working on open-iscsi.

The split did not really have much to do with the initial stability in
the data paths. It was more due to it getting merged with very little
real world testing.

There were stability issues with the interface because no one ever tried
creating a hw iscsi driver for it before it got merged, because software
iscsi does a host per session and hw drivers ended up doing a host per
port or some pci resource, and then boot support.

Most bugs fixed were due to skb handling, locking/atomic issues,
spec/rfc issues - not interface issues. But many large changes had to be
done to make the initial code support hw iscsi.

I agree open-iscsi is more difficult to debug than initiators that were
mostly in kernel like iscsi_sfnet. For open-iscsi the userspace part is
a single process, many operations cannot block, it has a ulgy state
model. And how it did its split does make things more difficult, because
it breaks up every operation into a different userspace to kernel call
(create a session is a call, create a conn is a call, pass a setting is
a call, bind a conn to a session is call, start the conn is a call,
etc). For software iscsi if open-iscsi just logged in to the target,
then passed everything to the kernel in one call then it would have been
a lot easier to debug. If Tomo's design does not have those issues then
it seems like it would not be that bad for software iscsi.

I think where doing a kernel/userspace split is going to be more
difficult is with supporting hw iscsi targets. With software iscsi you
can just pass down a socket and the settings more or less. With hw
iscsi, you want to be able to send the login related packets through the
iscsi port using the iscsi engine or hw/fw might be doing the actual
login process. But, if you are putting discovery (isns, sendtargets,
dhcp iscsi/isns options, slp, etc) in userspace then you have to solve
those issues for discovery so you can use the same interfaces for both.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/