linux-kernel - Re: [GIT PULL] SCSI fixes for 6.10-rc4

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]

Message-ID: <CAHk-=wgLGuYSgbS90MMudryOOjuWYeXaXGeGJRg9SVy1GmLKcQ@mail.gmail.com>
Date: Fri, 21 Jun 2024 18:56:45 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: "Martin K. Petersen" <martin.petersen@...cle.com>
Cc: James Bottomley <James.Bottomley@...senpartnership.com>, 
	Andrew Morton <akpm@...ux-foundation.org>, linux-scsi <linux-scsi@...r.kernel.org>, 
	linux-kernel <linux-kernel@...r.kernel.org>, Bart Van Assche <bvanassche@....org>
Subject: Re: [GIT PULL] SCSI fixes for 6.10-rc4

On Fri, 21 Jun 2024 at 18:48, Martin K. Petersen
<martin.petersen@...cle.com> wrote:
>
> The specific problem with mode pages is that there is no way to know
> whether a given page is supported without asking for it. Whereas for
> most of the other things we query at discovery time, the device provides
> a list of supported pages we can consult before we attempt to query the
> page itself.

Yes. I know.

But I also know that pretty much *EVERY* time the SCSI layer has
decided to start looking at some new piece of data, it turns out that
"Oh, look, all those devices have only ever been tested with operating
systems that did *NOT* look at that mode page or other thing, and
surprise surprise - not being tested means that it's buggy".

> It is a new feature in SCSI spearheaded by the Android folks. That's why
> there isn't a lot of information available about it elsewhere.

So no wonder random devices are buggy.

And I'm not putting down random devices. Quite the opposite. I'm
stating a well-known fact: untested things are buggy.

And no amount of "but but but it worked for me" is at all an argument.
If it hasn't been tested, it's almost certainly broken somewhere.

We've seen this over and over again.

> I am super picky about having good heuristics for when we should attempt
> to query a device for new protocol capabilities. In this case we lacked
> a reliable indicator that the feature was supported.

My argument is that things should be opt-in.

If it wasn't needed for the previous 30 years go SCSI history, it sure
as heck didn't suddenly become necessary today.

So you literally NEVER DO THIS unless the system admin has explicitly
enabled it.

That's what opt-in means.

And honestly, then the Android people can decide to opt in. Not random
other victims.

What's the advantage of just enabling random new features that have no
real use case today?

Put another way: why wasn't this an explicit opt-in from the get-go?
And why can't we make that be the rule going forward for the *NEXT*
time somebody introduces some random new mode page?

That was my ask.

           Linus