linux-kernel - Re: Inquiry data and emulated SG devices

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]

Message-id: <4716B56A.1090501@shaw.ca>
Date:	Wed, 17 Oct 2007 19:22:50 -0600
From:	Robert Hancock <hancockr@...w.ca>
To:	Mathieu Fluhr <mfluhr@...o.com>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	ide <linux-ide@...r.kernel.org>
Subject: Re: Inquiry data and emulated SG devices

(cc-ing linux-ide)

Mathieu Fluhr wrote:
> Hello all,
> 
> 
> First of all, let me introduce myself a little bit. I am the responsable
> for the development of the Nero Linux burning application. So I have
> access to all the source code of the application.
> 
> 
> Now let's go with the story: It seems that there is a slight problem in
> the libata (and also the new pata_xxx) interfaces with the data returned
> by the INQUIRY cmd since every S-ATA or IDE device is assumed to be a
> SCSI dev.
> 
> Normally, the IDE devices (physical type) can be differentied with the
> format field of the inquiry data, i.e. the last bytes (ANSI version) are
> set to 0 -> This is done and works great with USB external devices for
> example.
> 
> 
> The thing is that with S-ATA/IDE devices when using the libata/pata
> driver, the version field is (always?) set to 5, as any _real_ SCSI
> device, and thus the physical device type cannot be checked anymore.

This doesn't seem a very reliable way to identify an IDE device, as all
that 0 means is that the device does not claim conformance to any
standard. I would think it would be legitimate for an IDE device to put
a value like 5 in there as well, if it complies with SPC-4..

In the case of libata though, that appears to be due to this code in
drivers/ata/libata-scsi.c:

	/* ATAPI devices typically report zero for their SCSI version,
	 * and sometimes deviate from the spec WRT response data
	 * format.  If SCSI version is reported as zero like normal,
	 * then we make the following fixups:  1) Fake MMC-5 version,
	 * to indicate to the Linux scsi midlayer this is a modern
	 * device.  2) Ensure response data format / ATAPI information
	 * are always correct.
	 */
			if (buf[2] == 0) {
				buf[2] = 0x5;
				buf[3] = 0x32;
			}

This technically seems to go against what the SCSI/ATA Translation (SAT)
spec says regarding INQUIRY on ATAPI devices: "the SATL shall use the
ATA PACKET Command feature set to pass all INQUIRY commands and
parameter data to the ATAPI device without altering the INQUIRY
commands or the parameter data." However, it might realistically be
needed if the SCSI layer in the kernel has problems with a device
indicating it supports no SCSI version..

> 
> I cannot go so deep in details, but our burn engine is differentiating
> IDE and read-good-old-SCSI devices and handles them sometimes in a
> different way, so this differenciation is really important for us.
> 
>    -> How can I detect the real physical device type now?

I don't have a great answer off the top of my head..

-- 
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@...pamshaw.ca
Home Page: http://www.roberthancock.com/


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