linux-kernel - Re: [PATCH 1/2] nvme: make independent ns identify default

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <0076eb5e-6816-490e-abaf-a0a4a25a2915@bjorling.me>
Date: Wed, 9 Oct 2024 15:19:59 +0200
From: Matias Bjørling <m@...rling.me>
To: Christoph Hellwig <hch@....de>
Cc: kbusch@...nel.org, dlemoal@...nel.org, cassel@...nel.org,
 linux-nvme@...ts.infradead.org, linux-block@...r.kernel.org,
 linux-kernel@...r.kernel.org, Matias Bjørling
 <matias.bjorling@....com>
Subject: Re: [PATCH 1/2] nvme: make independent ns identify default

On 09-10-2024 09:46, Christoph Hellwig wrote:
> On Tue, Oct 08, 2024 at 04:55:02PM +0200, Matias Bjørling wrote:
>> However, the independent namespace data structure
>> is mandatory for devices that implement features from the 2.0+
>> specification. Therefore, we can check this data structure first. If
>> unavailable, retrieve the generic attributes from the NVM command set
>> identify namespace data structure.
> 
> I'm not a huge fan of this.  For pre-2.0 controllers this means
> we'll now send a command that will fail most of them time.  And for
> all the cheap low-end consumer device I'm actually worried that they'll
> get it wrong and break something.
> 

It's a good point. Damien, Keith, and I were debating it during ALPSS. 
They preferred the "send command and see if it fails" approach over 
writing specific conditions where it would apply. Note that Keith did 
suggest to avoid the command on 1.0 and 1.1 devices, and they were known 
to fail with unsupported CNS ids.

If making the check conditional, I think checking if the device follows 
2.0 specification isn't sufficient, as some devices may implement a 
subset of the 2.0 features (for example the independent ns data struct), 
while reporting as a 1.4 device.

Is there maybe better way, that isn't dependent on some feature being 
implemented (such as CRIMS capability)?