netdev - Re: [RFC PATCH net-next 6/6] ice: implement devlink parameters to control flash update

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: <20200716144208.4e602320@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Date:   Thu, 16 Jul 2020 14:42:08 -0700
From:   Jakub Kicinski <kubakici@...pl>
To:     Jacob Keller <jacob.e.keller@...el.com>
Cc:     netdev@...r.kernel.org, Jiri Pirko <jiri@...nulli.us>,
        Jesse Brandeburg <jesse.brandeburg@...el.com>,
        Tom Herbert <tom@...bertland.com>
Subject: Re: [RFC PATCH net-next 6/6] ice: implement devlink parameters to
 control flash update

On Thu, 16 Jul 2020 14:29:40 -0700 Jacob Keller wrote:
> On 7/15/2020 5:21 PM, Jacob Keller wrote:
> > Ok, that seems reasonable. Ofcourse we'll need to find something generic
> > enough that it can be re-used and isn't driver specific.
> 
> Hi Jakub,
> 
> I think I have something that will be more clear and will be sending a
> new RFC with the change this afternoon:
> 
> an extension to the DEVLINK_CMD_FLASH_UPDATE with a new parameter,
> "overwrite" with these values:
> 
> a) "nothing" (or maybe, "firmware-only" or "binary-only"?, need a way to
> clarify difference between settings/vital data and firmware program
> binary) will request that we do not overwrite any settings or fields.
> This is equivalent to the "PRESERVE_ALL" I had in the original proposal,
> where we will maintain all settings and all vital data, but update the
> firmware binary.
> 
> b) "settings" will request that the firmware overwrite all the settings
> fields with the contents from the new image. However, vital data such as
> the PCI Serial ID, VPD section, MAC Addresses, and similar "static" data
> will be kept (not overwritten). This is the same as the
> "PRESERVE_LIMITED" option I had in the original proposal
> 
> c) "all" or "everything" will request that firmware overwrite all
> contents of the image. This means all settings and all vital data will
> be overwritten by the contents in the new image.

Sorry but I'm still not 100% sure of what the use for this option is
beyond an OEM. Is it possible to reset the VPD, board serial, MAC
address etc. while flashing a FW image downloaded from a support site?
Would that mean that if I flash a rack with one FW image all NICs will
start reporting the same serial numbers and use the same MACs?

> d) if we need it, a "default" that would be the current behavior of
> doing whatever the driver default is? (since it's not clear to me what
> other implementations do but perhaps they all behavior as either
> "nothing" or "all"?

As a user I'd expect "nothing" to be the default. Same as your OS
update does not wipe out your settings. I think it's also better 
if the default is decided by Linux, not the drivers.

> I think I agree that "factory" settings doesn't really belong here, and
> I will try to push for finding an alternative way to allow access to
> that behavior. If we wanted it we could use "from_factory" to request
> that we overwrite the settings and  vital data "from" the factory
> portion, but I think that is pushing the boundary here a bit...
> 
> I am aiming to have a new patch up with this proposal

Probably best if we understand the use case more clearly, too. Since
you have this implemented in your tooling what are the scenarios where
factory is expected to be preferred over FW default?