linux-kernel - Re: [PATCH v3 3/3] scsi: Set allocation length to 255 for ATA Information VPD page

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]

Date:   Sun, 2 Jan 2022 23:09:24 -0500
From:   Douglas Gilbert <dgilbert@...erlog.com>
To:     "Maciej W. Rozycki" <macro@...am.me.uk>,
        Khalid Aziz <khalid@...ehiking.org>,
        "James E.J. Bottomley" <jejb@...ux.ibm.com>,
        "Martin K. Petersen" <martin.petersen@...cle.com>
Cc:     Christoph Hellwig <hch@....de>, Nix <nix@...eri.org.uk>,
        linux-scsi@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 3/3] scsi: Set allocation length to 255 for ATA
 Information VPD page

On 2022-01-02 6:23 p.m., Maciej W. Rozycki wrote:
> Set the allocation length to 255 for the ATA Information VPD page
> requested in the WRITE SAME handler, so as not to limit information
> examined by `scsi_get_vpd_page' in the supported vital product data
> pages unnecessarily.
> 
> Originally it was thought that Areca hardware may have issues with a
> valid allocation length supplied for a VPD inquiry, however older SCSI
> standard revisions[1] consider 255 the maximum length allowed and what
> has later become the high order byte is considered reserved and must be
> zero with the INQUIRY command.  Therefore it was unnecessary to reduce
> the amount of data requested from 512 as far down as to 64, arbitrarily
> chosen, and 255 would as well do.

Not arbitrary, 64 bytes would get all the fields less the 512 byte ATA
DEVICE IDENTIFY data field.

> With commit b3ae8780b429 ("[SCSI] Add EVPD page 0x83 and 0x80 to sysfs")
> we have since got the SCSI_VPD_PG_LEN macro, so use that instead.
> 
> References:
> 
> [1] "Information technology - Small Computer System Interface - 2",
>      WORKING DRAFT, X3T9.2, Project 375D, Revision 10L, 7-SEP-93, Section
>      8.2.5 "INQUIRY command", pp.104-108

Yes, 1992, long withdrawn and only used by several billion USB keys.

But the ATA Information VPD page first appeared in SAT around 2006 and the
length of that page was (and still is in SAT-5 drafts) "238h" (572 bytes
long (when the 4 byte header is considered)). So it needs 16 bits to
represent that length. SPC-3 (2005) bumped the allocation length field in
the INQUIRY command from 8 to 16 bits.

Finally SAT-1 in its approved references [2.2] says:
ISO/IEC 14776-453, SCSI Primary Commands - 3 (SPC-3) [ANSI INCITS 408-2005]

So any SAT layer that supplies the ATA Information VPD page should also
support (translating) an INQUIRY with a 16 bit allocation field.

How does your problem arise? Could USB mass storage be involved?

And this patch solves your problem by returning part of the ATA DEVICE
IDENTIFY data (which is 512 bytes long)? If so, why not say so.

And what about using 0x2ff as the INQUIRY allocation length? If the
broken device ignores the top byte, you get 255 bytes back. If a
correct device takes both bytes it should return 0x23c bytes after
resid is taken into account.

Not related to this patch:
sd_read_write_same() seems a strange name for a function given that
it is checking on WRITE SAME support. How about s/read/report/ ?
And calling scsi_report_opcode() on INQUIRY seems a weird time waster
(it actually checks if the SCSI version is < SPC-3 or does the check
on a _mandatory_ command). And for modern disks scsi_report_opcode()
is called 5 times. Why not call the REPORT SUPPORTED OPERATION CODES
command once and cache its result? It would save 4 commands in every
disk setup (or revalidation).

Doug Gilbert

> Signed-off-by: Maciej W. Rozycki <macro@...am.me.uk>
> Fixes: af73623f5f10 ("[SCSI] sd: Reduce buffer size for vpd request")
> Tested-by: Nick Alcock <nick.alcock@...cle.com>
> ---
> Changes from v2:
> 
> - Add Nick's Tested-by annotation.
> 
> No changes from v1.
> ---
>   drivers/scsi/sd.c |    5 +----
>   1 file changed, 1 insertion(+), 4 deletions(-)
> 
> linux-scsi-write-same-vpd-buffer.diff
> Index: linux-macro/drivers/scsi/sd.c
> ===================================================================
> --- linux-macro.orig/drivers/scsi/sd.c
> +++ linux-macro/drivers/scsi/sd.c
> @@ -3101,16 +3101,13 @@ static void sd_read_write_same(struct sc
>   	}
>   
>   	if (scsi_report_opcode(sdev, buffer, SD_BUF_SIZE, INQUIRY) < 0) {
> -		/* too large values might cause issues with arcmsr */
> -		int vpd_buf_len = 64;
> -
>   		sdev->no_report_opcodes = 1;
>   
>   		/* Disable WRITE SAME if REPORT SUPPORTED OPERATION
>   		 * CODES is unsupported and the device has an ATA
>   		 * Information VPD page (SAT).
>   		 */
> -		if (!scsi_get_vpd_page(sdev, 0x89, buffer, vpd_buf_len))
> +		if (!scsi_get_vpd_page(sdev, 0x89, buffer, SCSI_VPD_PG_LEN))
>   			sdev->no_write_same = 1;
>   	}
>   
>