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]

Date: Sat, 22 Jun 2024 09:24:03 -0700
From: Bart Van Assche <bvanassche@....org>
To: Linus Torvalds <torvalds@...ux-foundation.org>,
 "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>
Subject: Re: [GIT PULL] SCSI fixes for 6.10-rc4

On 6/21/24 6:56 PM, Linus Torvalds wrote:
> 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".

We got the message and we will do what we can to prevent future
regressions for USB devices.

As has been mentioned earlier, there is evidence in
sd_read_write_protect_flag() that SCSI devices may misbehave when
querying a mode page. However, I was not familiar with that code and
hence was not aware of the comments in that code. According to the git
history, these comments were added before 2005, that is before I started
reading the linux-scsi mailing list.

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

The new mode page has been introduced last year in SBC-5. UFS devices 
have a mix of SLC and TLC NAND internally and the new mode page allows
device vendors to reduce write amplification. This is important to UFS
device vendors.

I think that the new mode page is useful for all storage devices that
have a mix of slow and fast storage internally and hence that it is also
useful for some enterprise storage devices. This is why the new mode
page is read by default. But as has been mentioned above, we have
learned our lesson and will be much more careful in the future when
adding code that modifies the access pattern of the sd driver for USB
storage devices.

Thanks,

Bart.