linux-kernel - VIRTIO_BLK_T_SCSI_CMD in the virtio-blk protocol

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>] [day] [month] [year] [list]

Message-ID: <20090318060453.GA10650@lst.de>
Date:	Wed, 18 Mar 2009 07:04:53 +0100
From:	Christoph Hellwig <hch@....de>
To:	Rusty Russell <rusty@...tcorp.com.au>
Cc:	Christian Borntraeger <borntraeger@...ibm.com>,
	Anthony Liguori <aliguori@...ibm.com>,
	linux-kernel@...r.kernel.org
Subject: VIRTIO_BLK_T_SCSI_CMD in the virtio-blk protocol

Currently when virtio-blk gets a packet command request it just sets
the VIRTIO_BLK_T_SCSI_CMD flag in the type field, a zero sector and
sends down the request payload.

However for packet command requests they payload doesn't really say
anything about the command, we could need the cmd array to specify what
command (and offset/length) we're actually sending.

As far as I can see none of the backends actually implements
VIRTIO_BLK_T_SCSI_CMD support, so no harm is done here.

Should we just remove all handling of this flag until we have proper
support for it?  That would most like mean sending down another S/G
sement with the scsi command before the actual data.

Btw, is there a protocol spec for virtio-blk somewhere?
--
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/