netdev - Re: [RFC][PATCH 1/1] cxgb3i: cxgb3 iSCSI initiator

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:	Sun, 10 Aug 2008 09:54:46 -0500
From:	James Bottomley <James.Bottomley@...senPartnership.com>
To:	Jeff Garzik <jgarzik@...ox.com>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Roland Dreier <rdreier@...co.com>,
	Steve Wise <swise@...ngridcomputing.com>, davem@...emloft.net,
	Divy Le Ray <divy@...lsio.com>, Karen Xie <kxie@...lsio.com>,
	netdev@...r.kernel.org, open-iscsi@...glegroups.com,
	michaelc@...wisc.edu, daisyc@...ibm.com, wenxiong@...ibm.com,
	bhua@...ibm.com, Dimitrios Michailidis <dm@...lsio.com>,
	Casey Leedom <leedom@...lsio.com>,
	linux-scsi <linux-scsi@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [RFC][PATCH 1/1] cxgb3i: cxgb3 iSCSI initiator

On Sun, 2008-08-10 at 08:49 -0400, Jeff Garzik wrote:
> Alan Cox wrote:
> >>  - It doesn't work in theory, because the suggestion (I guess) is that
> >>    the iSCSI HBA has its own MAC and IP and behaves like a separate
> > 
> > The iSCSI HBA is its own system - that is the root of the problem.
> 
> Indeed.
> 
> Just like with TOE, from the net stack's point of view, an iSCSI HBA is 
> essentially a wholly asynchronous remote system [with a really fast 
> communication bus like PCI Express].
> 
> As such, the task becomes updating the net stack such that 
> formerly-private resources are now shared with an independent, external 
> system...  with all the complexity, additional failure modes, and 
> additional security complications that come along with that.

What's wrong with making it configurable identically to current software
iSCSI?  i.e. plumb the thing into the current iscsi transport class so
that we use the standard daemon for creating and binding sessions?
Then, only once the session is bound do you let your iSCSI TOE stack
take over.

That way the connection appears to the network as completely normal,
because it has an open socket associated with it; and, since the
transport class has done the connection login, it even looks like a
normal iSCSI connection to the usual tools.  iSCSI would manage
connection and authentication, so your TOE stack can be simply around
the block acceleration piece (i.e. you'd need to get the iscsi daemon to
do relogin and things).

I would assume net will require some indicator that the opened
connection has been subsumed, so it knows not to try to manage it, but
other than that I don't see it will need any alteration.  The usual
tools, like netfilter could even use this information to know the limits
of their management.

If this model works, we can use it for TOE acceleration of individual
applications (rather than the entire TCP stack) on an as needed basis.

This is like the port stealing proposal, but since the iSCSI daemon is
responsible for maintaining the session, the port isn't completely
stolen, just switched to accelerator mode when doing the iSCSI offload.

James

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html