linux-kernel - Re: [PATCH] nvme: prevent id ctrl csi for specs below 2.0

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] [day] [month] [year] [list]

Message-ID: <ZP92wmbIHpzZKEyZ@kbusch-mbp.dhcp.thefacebook.com>
Date:   Mon, 11 Sep 2023 13:21:23 -0700
From:   Keith Busch <kbusch@...nel.org>
To:     Alexander Motin <mav@...ystems.com>
Cc:     Ameer Hamza <ahamza@...ystems.com>, linux-nvme@...ts.infradead.org,
        axboe@...nel.dk, hch@....de, sagi@...mberg.me,
        linux-kernel@...r.kernel.org, edmund.nadolski@...ystems.com
Subject: Re: [PATCH] nvme: prevent id ctrl csi for specs below 2.0

On Mon, Sep 11, 2023 at 03:29:34PM -0400, Alexander Motin wrote:
> On 11.09.2023 14:40, Keith Busch wrote:
> > On Mon, Sep 11, 2023 at 02:26:41AM +0500, Ameer Hamza wrote:
> > > The 'id ctrl csi' command was introduced in version 2.0, as specified
> > > in Section 5.17.2.6 of the NVME Base Specification 2.0. Executing this
> > > command on previous NVMe versions returns an "Invalid Field" error,
> > > and the error entry is saved in the log page. Although, Commit
> > > c917dd96fe41 ("nvme: skip optional id ctrl csi if it failed") reduced
> > > the error occurrences, but the error persisted during the initial
> > > module load. This patch ensures the command isn't executed on versions
> > > older than 2.0, and it also eliminates the skip implementation because
> > > NVME_ID_CNS_CS_CTRL is expected to succeed with version 2.0.
> > 
> > NVMe TP's are allowed to be implemented by versions lower than the
> > release that first included it. I recall the first nvme controller I'd
> > seen that implemented this identification reported itself as 1.4.
> 
> Then there must be a way to detect it.  How otherwise it is not a standard
> violation to send arbitrary effectively vendor-specific commands to a drive?

For identification structures, you detect support for these by seeing if
the device responds with success or not.

Not sure what you mean by "standard violation". The standard defines
ways for the controller to respond when it receives an unrecognized
command.