linux-kernel - Re: "Fix ATAPI transfer lengths" causes CD writing regression

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:	Thu, 01 Nov 2007 05:48:15 -0400
From:	Jeff Garzik <jeff@...zik.org>
To:	Jens Axboe <jens.axboe@...cle.com>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Daniel Drake <dsd@...too.org>
CC:	linux list <linux-kernel@...r.kernel.org>,
	linux-ide@...r.kernel.org, Tejun Heo <htejun@...il.com>,
	Albert Lee <albertcc@...ibm.com>
Subject: Re: "Fix ATAPI transfer lengths" causes CD writing regression

Ok, gave this a hard look.

This is basically a behavior change with regards to how we program the 
bcount(low) and bcount(high) registers.

Issues about FIFO draining and devices returning too-much data are 
ultimately tangential.  Furthermore, this is an ATAPI PIO issue, as 
demonstrated by (a) Alan's patch did not change DMA lbam/lbah 
programming and (b) Daniel's report of the message "ata2.00: 66 bytes 
trailing data" which occurs in the PIO state machine.

To survey the behaviors for ATAPI PIO:

ide-cd:			read/write commands,	blimit = 32k
			others cmds,		blimit = xfer_len

old libata (pre-Alan):	blimit = 8k

new libata behavior:	blimit = xfer_len

thus Alan's patch was moving us CLOSER to ide-cd's behavior (if we 
ignore read/write commands for the moment, which are not at issue).

and the end result is that the change from old-libata to new-libata 
behavior broke Daniel's case, which is a device known to ignore the SCSI 
command CDB's allocation length field.

Additionally, let's add some background:

libata was originally written for first-gen SATA controllers (incl. 
first-gen SATA bridges), most notably ata_piix, the controller Daniel is 
using.

I chose blimit 8k because I felt that matches the maximum size of a SATA 
Data FIS.  I felt -- this was a wild-added guess -- that setting blimit 
thusly would properly configure all the magic internal FIFOs and data 
buffers in silicon that handled these crazy ATAPI devices with random 
transfer lengths.

I am not drawing any conclusions yet, but I'm thinking that blimit=8k 
may be a better choice for SATA ATAPI.

Other comment:

* as Tejun noted in IRC, we don't have a clear idea of what triggered 
the HSM violation.  turning on debugging printk's would help, but 
unfortunately that means turning them on for everything, including hard 
drives.

	Jeff

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