netdev - RE: [PATCH net-next 10/15] ice: display some stored NVM versions via devlink info

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: <8403365008c14c959ad9ca63f29891a4@intel.com>
Date:   Mon, 1 Feb 2021 18:15:20 +0000
From:   "Keller, Jacob E" <jacob.e.keller@...el.com>
To:     Jakub Kicinski <kuba@...nel.org>,
        "Nguyen, Anthony L" <anthony.l.nguyen@...el.com>
CC:     "davem@...emloft.net" <davem@...emloft.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "sassmann@...hat.com" <sassmann@...hat.com>,
        "Brelinski, TonyX" <tonyx.brelinski@...el.com>
Subject: RE: [PATCH net-next 10/15] ice: display some stored NVM versions via
 devlink info



> -----Original Message-----
> From: Jakub Kicinski <kuba@...nel.org>
> Sent: Friday, January 29, 2021 10:38 PM
> To: Nguyen, Anthony L <anthony.l.nguyen@...el.com>
> Cc: davem@...emloft.net; Keller, Jacob E <jacob.e.keller@...el.com>;
> netdev@...r.kernel.org; sassmann@...hat.com; Brelinski, TonyX
> <tonyx.brelinski@...el.com>
> Subject: Re: [PATCH net-next 10/15] ice: display some stored NVM versions via
> devlink info
> 
> On Thu, 28 Jan 2021 16:43:27 -0800 Tony Nguyen wrote:
> > When reporting the versions via devlink info, first read the device
> > capabilities. If there is a pending flash update, use this new function
> > to extract the inactive flash versions. Add the stored fields to the
> > flash version map structure so that they will be displayed when
> > available.
> 
> Why only report them when there is an update pending?
> 
> The expectation was that you'd always report what you can and user
> can tell the update is pending by comparing the fields.

The data in the inactive bank might not be a valid image. There's no straightforward way to verify this except by detecting that we're about to switch banks on the next reboot. If we report this information all the time, in some cases it would be reporting numbers which are meaningless and not actually valid version information. I had assumed this would lead to more confusion than only reporting the data when the bank has data we know is going to be activated soon