linux-kernel - Re: [PATCH] Use ida_simple for SCSI iSCSI transport session id

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]

Message-ID: <20160217223708.w35zn3h66gwv5jlw@straylight.hirudinean.org>
Date:	Wed, 17 Feb 2016 14:37:08 -0800
From:	Chris Leech <cleech@...hat.com>
To:	open-iscsi@...glegroups.com
Cc:	Lee Duncan <lduncan@...e.com>, linux-scsi@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Use ida_simple for SCSI iSCSI transport session id

On Tue, Feb 16, 2016 at 12:40:12PM -0600, Mike Christie wrote:
> On 02/15/2016 12:26 PM, Chris Leech wrote:
> > On Fri, Feb 12, 2016 at 09:54:51AM -0800, James Bottomley wrote:
> >> On Fri, 2016-02-12 at 09:38 -0800, Lee Duncan wrote:
> >>> The scsi_transport_iscsi module already uses the ida_simple
> >>> routines for managing the target ID, if requested to do
> >>> so. This change replaces an ever-increasing atomic integer
> >>> that tracks the session ID itself with the ida_simple
> >>> family of routines. This means that the session ID
> >>> will be reclaimed and can be reused when the session
> >>> is freed.
> >>
> >> Is reusing session ID's really a good idea?  For sequential sessions it
> >> means that the ID of the next session will be re-used, i.e. the same as
> >> the previous sessions, which could lead to target confusion.  I think
> >> local uniqueness of session IDs is more important than wrap around
> >> because sessions are short lived entities and the chances of the same
> >> session being alive by the time we've wrapped is pretty tiny.
> > 
> > I've got a few complaints about target resources being tied up because
> > we don't reuse session IDs.  The ISID becomes a component in the
> > I_T nexus identifier, so changing it invalidates persistent reservations.
> > 
> >> If you can demostrate a multi-target problem, perhaps we should rather
> >> fix this by making the next session id a target local quantity?
> > 
> > Mike's got a good point that we don't really need to base the ISID off
> > of our local session identifier (kobject name).  I think getting reuse
> > right may be a bit trickier than being a target local value, because it
> > needs to be unique across target portal groups.  Which probably furthers
> > the argument that we should deal with that in the userspace tools.
> > 
> > If we plan to split the protocol ISID cleanly from the kobject name,
> > I guess the question is if aggressive reuse of the local identifier is
> > better than dealing with the unlikely collision on rollover?
> 
> I thought Lee's patch to convert the host_no from a atomic_t to ida
> based was merged in Martin's tree. If that is going upstream, then I
> thought you would want to fix the session id too.
> 
> Is the concern similar to /dev/sdX reuse and bad apps? In this case,
> some app might do a logout and login, but not update the sysfs mapping.
> You could then hit corruption due to the sysfs session id now mapping to
> a different target.

OK, I don't want to cause a rehash of the same concerns. I took a look
at whatever code I could think to check in that builds on top of the
Open-iSCSI tools, and I don't think this will break anything.

I'm OK with this.

- Chris