Re: Is the possible cross-talking between unrelated file-descriptors on bsg-device by design?

[Douglas Gilbert <dgilbert@interlog.com>]

On 2017-09-19 10:56 AM, Benjamin Block wrote:
> Hello linux-block,
> 
> I wrote some tests recently to test patches against bsg.c and bsg-lib.c,
> and while writing those I noticed something strange:
> 
> When you use the write() and read() call on multiple file-descriptors
> for a single bsg-device (FC or SCSI), it is possible that you get
> cross-talk between those different file-descriptors.
> 
> E.g.: You have two independent processes open a FD on /dev/bsg/fc_host0
> and you send commands via write() in both processes, when they both do
> read() later on - to read the response for the commands they send before
> -, it is possible that process A gets the response (Sense-Data,
> FC-Protocol-Data, ...) for a command that process B wrote and vis-a-vis.
> 
> I noticed this because in my tests I 'tag' each command I send with
> write() via a value I write into the usr_ptr field of sg_io_v4. When I
> later user read() to receive responses I check for this tag in a
> hash-table and so can look up the original command. When I used this and
> spawned multiple processes with the same target bsg-device, I got
> responses for commands I don't have tags for in my hash-table, so they
> were written by an other process. This never happend when I only spawn
> one test-process.
> 
> This seems awfully contra-productive.. so much that I don't see any
> point in allowing users to open more than one FD per bsg-device, because
> that would inevitably lead to very hard to debug 'bugs'. And I wonder if
> this is really by design or some regression that happend over time.
> 
> I looked at the code in bsg.c and yes, it seems this is what is coded
> right now. We have a hash-table which manages all 'struct bsg_device's
> who are indexed by device-minors, so one hash-table entry per
> device-node.
> 
> So eh, long talk short question, is that intended?

Hi,
About once a year I point out that major misfeature in the bsg driver
and no-one seems to care. Most recently I pointed it out in a
discussion about SCSI SG CVE-2017-0794 6 days ago:
   " ... Last time I looked at the bsg driver, a SCSI command
     could be issued on one file descriptor and its data-in block
     and SCSI status delivered to another file descriptor to the
     same block device (potentially in another process). IOW chaos"

It is hard to imagine any sane application relying on this bizarre
behaviour so fixing it should not break any applications. My guess
is that it would require a non-trivial patch set to fix. Would you
like to volunteer?


In the same post I asked (thinking it was cc-ed to this list):
"BTW Is there a NVMe pass-through?"

And the answer is: yes there is in include/uapi/linux/nvme_ioctl.h
which has struct nvme_user_io and struct nvme_passthru_cmd plus
several ioctl constants. See the smartmontool repository for
examples of how to use them. I also discovered there is a SCSI
to NVMe translation layer (SNTL) hiding in some kernels. Hence
commands like this:
    sg_inq /dev/nvme0    ## that's a 'char' device, and ...
    sg_vpd /dev/nvme0n1  ## that's a block device "namespace 1"

work as expected. Ah, I spoke too soon ... in another post I have
been informed that the SNTL has now been removed from the kernel.
Just goes to show the human stupidity is still infinite :-)

Doug Gilbert