linux-kernel - VIRTIO_BLK_T_SCSI_CMD handling in virtio-blk

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

Date:	Wed, 18 Mar 2009 02:09:19 -0400
From:	Christoph Hellwig <hch@...radead.org>
To:	Rusty Russell <rusty@...tcorp.com.au>
Cc:	Anthony Liguori <aliguori@...ibm.com>,
	Christian Borntraeger <borntraeger@...ibm.com>,
	linux-kernel@...r.kernel.org
Subject: VIRTIO_BLK_T_SCSI_CMD handling in virtio-blk

Currently virtio-blk just sends down the payload for packet command
requests, setting the VIRTIO_BLK_T_SCSI_CMD flag in the type field and
zeroing out the sector field.

But to make any sense of the payload of a packet command we need the
scsi command block (request->cmd) which specifies the operation,
location and length for this command.

All backends that I checked just fail VIRTIO_BLK_T_SCSI_CMD commands, so
AFAICS no harm is done.  But should we really keep this broken support
in the protocol around?  If we do want to support packet commands in
the future we should probably just add the command as the first S/G list
entry.

Is there an actual protocol spec for virtio-blk somewhere to write these
subtilities down?  Or an list of implementations to check at least?
--
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/