linux-kernel - Re: [PATCH 4/4] target: Add a user-passthrough backstore

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: <541CCBD1.8050606@redhat.com>
Date:	Fri, 19 Sep 2014 17:35:29 -0700
From:	Andy Grover <agrover@...hat.com>
To:	Alex Elsayed <eternaleye@...il.com>, target-devel@...r.kernel.org
CC:	linux-scsi@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 4/4] target: Add a user-passthrough backstore

On 09/19/2014 04:51 PM, Alex Elsayed wrote:

>> Not sure I follow..  How does the proposed passthrough mode prevent
>> someone from emulating OSDs, media changers, optical disks or anything
>> else in userspace with TCMU..?
>>
>> The main thing that the above comments highlight is why attempting to
>> combine the existing in-kernel emulation with a userspace backend
>> providing it's own emulation can open up a number of problems with
>> mismatched state between the two.
>
> It doesn't prevent it, but it _does_ put it in the exact same place as PSCSI
> regarding the warnings on the wiki. It means that if someone wants to
> implement (say) the optical disc or OSD CDBs, they then lose out on ALUA &co
> unless they implement it themselves - which seems unnecessary and painful,
> since those should really be disjoint. In particular, an OSD backed by RADOS
> objects could be a very nice thing indeed, _and_ could really benefit from
> ALUA.

Some possible solutions:

1) The first time TCMU sees an opcode it passes it up and notes whether 
it is handled or not. If it was handled then future cmds with that 
opcode are passed up but not retried in the kernel. If it was not 
handled then it and all future commands with that opcode are handled by 
the kernel and not passed up.

2) Same as #1 but TCMU operates on SCSI spec granularity - e.g. handling 
any SSC opcode means userspace must handle all SSC commands.

3) Like #2 but define opcode groupings that must all be implemented 
together, independent of the specifications.

4) Have passthrough mode set at creation, but with more than two modes, 
either grouped by SCSI spec or our own groupings.

5) Never pass up certain opcodes, like the ALUA ones or whatever.

Have a good weekend -- Andy

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