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] [day] [month] [year] [list]

Date:   Fri, 17 Jul 2020 10:21:23 -0700
From:   Jacob Keller <jacob.e.keller@...el.com>
To:     Jakub Kicinski <kubakici@...pl>, Tom Herbert <tom@...bertland.com>
Cc:     netdev@...r.kernel.org, Jiri Pirko <jiri@...nulli.us>,
        Jesse Brandeburg <jesse.brandeburg@...el.com>
Subject: Re: [RFC PATCH net-next 6/6] ice: implement devlink parameters to
 control flash update



On 7/16/2020 3:18 PM, Jakub Kicinski wrote:
> On Thu, 16 Jul 2020 14:52:15 -0700 Jacob Keller wrote:
>> On 7/16/2020 2:42 PM, Jakub Kicinski wrote:
>>> 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?
>>
>> I think the intent here is for OEMs which would generate/customize the
>> images, though I've also been told it may be useful to get a card out of
>> some situation where firmware preservation was broken.. (No, I don't
>> really have more details on what specifically the situation might be).
>> Obviously in most update cases I don't think we expect this to be used.
> 
> What I'm getting at is that this seems to inherently require a special
> FW image which will carry unique IDs, custom-selected for a particular
> board. So I was hoping we can infer the setting from the image being
> flashed. But perhaps that's risky.
> 


Hmm. I don't think we have any obvious way to tell this.

> Let's make sure the description of the option captures the fact that
> this is mostly useful in manufacturing and otherwise very rarely needed.
> 

Sure. I'll try to make that clear in the documentation and in the naming.

>>>> 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.
>>
>> Right, but I wasn't sure what other drivers/devices implement today and
>> didn't want  to end up in a "well we don't behave that way so you just
>> changed our behavior"..? Hmm. If they all behave this way today then
>> it's fine to make "nothing" the default and modify all implementations
>> to reject other options.
> 
> Understood. Let's make things clear in the submission and CC
> maintainers of all drivers which implement devlink flashing today.
> Let them complain. If we're too cautious we'll never arrive on sane
> defaults.

Yep.

I hope to have this out today, I got sidetracked yesterday.

Regards,
Jake