RE: [PATCH net-next 03/15] ice: read security revision to ice_nvm_info and ice_orom_info

-----Original Message-----
From: Jakub Kicinski <kuba@kernel.org>
Sent: Friday, January 29, 2021 10:44 PM
To: Nguyen, Anthony L <anthony.l.nguyen@intel.com>
Cc: davem@davemloft.net; Keller, Jacob E <jacob.e.keller@intel.com>;
netdev@vger.kernel.org; sassmann@redhat.com; Brelinski, TonyX
[off-list ref]
Subject: Re: [PATCH net-next 03/15] ice: read security revision to ice_nvm_info
and ice_orom_info

On Thu, 28 Jan 2021 16:43:20 -0800 Tony Nguyen wrote:

quoted

From: Jacob Keller <jacob.e.keller@intel.com>

The main NVM module and the Option ROM module contain a security
revision in their CSS header. This security revision is used to
determine whether or not the signed module should be loaded at bootup.
If the module security revision is lower than the associated minimum
security revision, it will not be loaded.

The CSS header does not have a module id associated with it, and thus
requires flat NVM reads in order to access it. To do this, take
advantage of the cached bank information. Introduce a new
"ice_read_flash_module" function that takes the module and bank to read.
Implement both ice_read_active_nvm_module and
ice_read_active_orom_module. These functions will use the cached values
to determine the active bank and calculate the appropriate offset.

Using these new access functions, extract the security revision for both
the main NVM bank and the Option ROM into the associated info structure.

Add the security revisions to the devlink info output. Report the main
NVM bank security revision as "fw.mgmt.srev". Report the Option ROM
security revision as "fw.undi.srev".

A future patch will add the associated minimum security revisions as
devlink flash parameters.

This needs a wider discussion. Hopefully we can agree on a reasonably
uniform way of handling this across vendors. Having to fish out
_particular_ version keys out and then target _particular_ parameters
for each vendor is not great.

Yea, I can see how that would be problematic. It does seem like some sort of tied interface would make sense.

First off - is there a standard around the version management that we
can base the interface on? What about key management? There's gotta be
a way of revoking keys too, right?

I am not sure. None of the implementation I've written deals with key management and it wasn't an ask.

I'd recommend separating the srev patches out of the series so the
other ones can land.

Sure, We can do that.