linux-kernel - Re: [ 38/48] SCSI & usb-storage: add try_rc_10

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:	Mon, 2 Jul 2012 11:52:23 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Hans de Goede <hdegoede@...hat.com>
Cc:	Ben Hutchings <ben@...adent.org.uk>, linux-kernel@...r.kernel.org,
	stable@...r.kernel.org, akpm@...ux-foundation.org,
	alan@...rguk.ukuu.org.uk, Alan Stern <stern@...land.harvard.edu>,
	"James E.J. Bottomley" <JBottomley@...allels.com>,
	Matthew Dharm <mdharm-usb@...-eyed-alien.net>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [ 38/48] SCSI & usb-storage: add try_rc_10_first flag

On Mon, Jul 2, 2012 at 12:10 AM, Hans de Goede <hdegoede@...hat.com> wrote:
>
> So since 3.2 already tries READ_CAPACITY(10) first, this patch is
> not needed. It does not harm either, and if the scsi level reporting
> change ever finds its way into 3.2 stable (which it should not
> IMHO), then this patch will be needed.

Yeah, it should definitely not make it into stable. In fact, I'd
rather remove it from mainline too. The whole idea to do
READ_CAPACITY_16 by default was moronic.

James? Why does the SCSI subsystem always do these idiotic defaults?
We *know* that devices are buggy. Sure, USB storage tends to be
buggier than most, but the whole idea of "let's use the new way of
reporting that gets almost no testing" is just wrong.

I don't think the USB layer should have needed to work around this. I
don't think there should be a "try_10b" flag at all. I think the SCSI
code should just *never* do the 16b version unless it has done the 10b
version first and determined that the size doesn't fit.

And the code already had that logic got the read_10b case. The whole
logic to do 16b by default was crap. It *used* to at least only do it
for disks that were marked as having "protection", now it wants to do
it for anything that should be able to handle it. Which is bogus. The
whole "let's assume devices get it right" mindset is broken.

The mindset should be "let's assume devices are buggy, and be careful".

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