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:17:55 +0400
From:	James Bottomley <James.Bottomley@...senPartnership.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	"Nicholas A. Bellinger" <nab@...ux-iscsi.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 10:51 -0700, Linus Torvalds wrote:
> On Sat, Jul 23, 2011 at 9:39 AM, James Bottomley
> <James.Bottomley@...senpartnership.com> wrote:
> >
> > I've asked you twice for input on the patch doing this in userspace,
> > which was posted five weeks ago.  Just ignoring something is
> > unacceptable behaviour ... what do I have to do to get your attention?
> > NAK the patch set?
> 
> So what's the advantage of user space?
> 
> Traditionally, kernel/userspace splits have been:
>  - fragile as hell
>  - more code
>  - slower
>  - complicated to set up
>  - problematic with backwards compatibility issues
> and these days when I see some kernel functionality that needs user
> space support, I just go "f*ck, that's going to be a pain".
> 
> So I think the "that part can be done in user space" argument is
> fundamentally crap.
> 
> Now, if it is an issue of "that can be done BETTER in user space
> BECAUSE xyz", then that's a different issue. I haven't seen that
> argument, though.

Well, this is essentially the argument.  The iSCSI authentication code
follows a standard which originally had 4 different authentication
methods (of which CHAP is just one) but which is now up to about 8 I
think and rising.  It would be a massive amount of code to put them all
in kernel, plus the authentication isn't a fast path thing; it's done
once at login.  We already have the code to do this (although from the
client side, not the server side) in userspace in the initiator.

The prototype implementation, is very clean: it does the authenticated
login and then passes the connected socket to the kernel for operations,
so there's no real fragile state to pass across.

There are a couple of reasons why user space makes sense apart from the
existing code and the clean separation of setup from operation: some of
the auth methods involve complex algorithms and debugging them in
userspace is just easier, plus it allows easy backward compatible
addition of new authentication mechanisms without having to respin a
kernel.

Quite a few other authentication mechanisms (like wireless and ipsec)
are in userspace for the setup and negotiation and in-kernel for the
operation, so it's a well understood paradigm.

James

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