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 for Android: free password hash cracker in your pocket

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

Date:	Sat, 23 Jul 2011 21:59:55 -0700
From:	"Nicholas A. Bellinger" <nab@...ux-iscsi.org>
To:	Mike Christie <michaelc@...wisc.edu>
Cc:	linux-iscsi-target-dev@...glegroups.com,
	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 Sat, 2011-07-23 at 22:08 -0500, Mike Christie wrote:
> 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.
> 

In the various kernel/user split implementations, I completely agree
that the open-iscsi is more difficult and painful than what Tomo has
proposed..

However, my main issue is still with moving the default login paths to a
single threaded userspace daemon that needs to be fully aware of lots of
dynaminc state changes in /sys/kernel/config/target/iscsi.  Implementing
a userspace daemon that needs to be aware of this is going to require an
kernel/user split quickly moving towards the 'break up every operation
into a different call' arena, that puts us back open-iscsi type split
terrority.

> 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.

Fair point.  I would also expect HW iscsi to integrate into the same
control plane and python library for an consistent API to application
devels here.

--nab

--
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/