linux-kernel - Re: [PATCH v3] nvme: update firmware version after commit

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: <ZUUCE88vOi6Wj69a@kbusch-mbp.dhcp.thefacebook.com>
Date:   Fri, 3 Nov 2023 08:22:11 -0600
From:   Keith Busch <kbusch@...nel.org>
To:     Christoph Hellwig <hch@....de>
Cc:     Daniel Wagner <dwagner@...e.de>, linux-nvme@...ts.infradead.org,
        linux-kernel@...r.kernel.org,
        Niklas Cassel <Niklas.Cassel@....com>,
        Kenji Tomonaga <tkenbo@...il.com>
Subject: Re: [PATCH v3] nvme: update firmware version after commit

On Fri, Nov 03, 2023 at 02:58:57PM +0100, Christoph Hellwig wrote:
> On Fri, Nov 03, 2023 at 01:11:02PM +0100, Daniel Wagner wrote:
> > This particular firmware seem to interpret afi one based, while
> > the this patch assumes it is zero based
> 
> >   Active Firmware Info (AFI): Specifies information about the active
> >                               firmware revision.
> > 
> >   Bit 7    is reserved.
> >   Bits 6:4 indicates the firmware slot that is going to be activated
> >            at the next Controller Level Reset. If this field is 0h,
> >            then the controller does not indicate the firmware slot that
> >            is going to be activated at the next Controller Level Reset.
> >   Bit 3    is reserved.
> >   Bits 2:0 indicates the firmware slot from which the actively running
> >            firmware revision was loaded.
> > 
> > 
> > It's not clear to me if afi bits 2:0 is zero or one based. Bits 6:4
> > indicate to be 1 based.
> 
> All 0's based (what a stupid term..) fields in NVMe are explicitly
> marked as such.  And even if that wasn't the case I'd very much
> expect the same encoding for the two sub-fields.

Yeah, it's just the firmware slot number, taken literally. AFI = 1 means
slot 1, AFI = 2 means slot 2, etc... Slot 0 either has special meaning
(firmware commit SF field, or fw log AFI bits 6:4), or is reserved
value, like in Identify Controller FRMW.NOFS, and has no place in the FW
Slot Info log page.

Our first slot in the log page is defined as slot one, so we have to
subtract one from the AFI field to index into the slot array. I messed
up for not catching that earlier, but thanks for pointing it out now.