On Thu, 28 Jan 2021 16:43:20 -0800 Tony Nguyen wrote: > From: Jacob Keller <jacob.e.kel...@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. 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'd recommend separating the srev patches out of the series so the other ones can land.
