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: <20200726071834.GC2216@nanopsycho>
Date:   Sun, 26 Jul 2020 09:18:34 +0200
From:   Jiri Pirko <jiri@...nulli.us>
To:     Jacob Keller <jacob.e.keller@...el.com>
Cc:     Jakub Kicinski <kuba@...nel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Tom Herbert <tom@...bertland.com>,
        Jiri Pirko <jiri@...lanox.com>,
        Jonathan Corbet <corbet@....net>,
        Michael Chan <michael.chan@...adcom.com>,
        Bin Luo <luobin9@...wei.com>,
        Saeed Mahameed <saeedm@...lanox.com>,
        Leon Romanovsky <leon@...nel.org>,
        Ido Schimmel <idosch@...lanox.com>,
        Danielle Ratson <danieller@...lanox.com>
Subject: Re: [RFC PATCH net-next v2 6/6] devlink: add overwrite mode to flash
 update

Wed, Jul 22, 2020 at 08:21:22PM CEST, jacob.e.keller@...el.com wrote:
>
>
>On 7/22/2020 9:52 AM, Jakub Kicinski wrote:
>> On Wed, 22 Jul 2020 15:30:05 +0000 Keller, Jacob E wrote:
>>>> So perhaps we can introduce something like "component mask", which would
>>>> allow to flash only part of the component. That is basically what Jacob
>>>> has, I would just like to have it well defined.
>>>
>>> So, we could make this selection a series of masked bits instead of a
>>> single enumeration value.
>> 
>> I'd still argue that components (as defined in devlink info) and config
>> are pretty orthogonal. In my experience config is stored in its own
>> section of the flash, and some of the knobs are in no obvious way
>> associated with components (used by components).
>> 
>> That said, if we rename the "component mask" to "update mask" that's
>> fine with me.
>> 
>> Then we'd have
>> 
>> bit 0 - don't overwrite config
>> bit 1 - don't overwrite identifiers
>> 
>> ? 
>> 
>> Let's define a bit for "don't update program" when we actually need it.
>> 
>
>
>Ok. And this can be later extended with additional bits with new
>meanings should the need arise.
>
>Additionally, drivers can ensure that the valid combination of bits is
>set. the drivers can reject requests for combinations that they do not
>support.

Makes sense.

>
>I can make that change.
>
>My preference is that "0" for a bit means do not overwrite while "1"
>means overwrite. This way, if/when additional bits are added, drivers
>won't need to be updated to reject such requests. If we make "1" the "do
>not overwrite" then we'd have a case where drivers must update to ensure
>they reject requests which don't set the bit.

0 should be default and driver should bahave accordingly.


>
>Thanks,
>Jake

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ