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  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Fri, 18 Sep 2020 17:13:24 -0700
From:   Shannon Nelson <>
To:     Jacob Keller <>,
Cc:     Jiri Pirko <>, Jakub Kicinski <>,
        Jonathan Corbet <>,
        Michael Chan <>,
        Bin Luo <>,
        Saeed Mahameed <>,
        Leon Romanovsky <>,
        Ido Schimmel <>,
        Danielle Ratson <>
Subject: Re: [net-next v7 0/5] devlink flash update overwrite mask

On 9/18/20 4:42 PM, Jacob Keller wrote:
> This series introduces support for a new attribute to the flash update
> This attribute is a bitfield which allows userspace to specify what set of
> subfields to overwrite when performing a flash update for a device.
> The intention is to support the ability to control the behavior of
> overwriting the configuration and identifying fields in the Intel ice device
> flash update process. This is necessary  as the firmware layout for the ice
> device includes some settings and configuration within the same flash
> section as the main firmware binary.
> This series, and the accompanying iproute2 series, introduce support for the
> attribute. Once applied, the overwrite support can be be invoked via
> devlink:
>    # overwrite settings
>    devlink dev flash pci/0000:af:00.0 file firmware.bin overwrite settings
>    # overwrite identifiers and settings
>    devlink dev flash pci/0000:af:00.0 file firmware.bin overwrite settings overwrite identifiers
> To aid in the safe addition of new parameters, first some refactoring is
> done to the .flash_update function: its parameters are converted from a
> series of function arguments into a structure. This makes it easier to add
> the new parameter without changing the signature of the .flash_update
> handler in the future. Additionally, a "supported_flash_update_params" field
> is added to devlink_ops. This field is similar to the ethtool
> "supported_coalesc_params" field. The devlink core will now check that the
> DEVLINK_SUPPORT_FLASH_UPDATE_COMPONENT bit is set before forwarding the
> component attribute. Similarly, the new overwrite attribute will also
> require a supported bit.
> Doing these refactors will aid in adding any other attributes in the future,
> and creates a good pattern for other interfaces to use in the future. By
> requiring drivers to opt-in, we reduce the risk of accidentally breaking
> drivers when ever we add an additional parameter. We also reduce boiler
> plate code in drivers which do not support the parameters.
> Cc: Jiri Pirko <>
> Cc: Jakub Kicinski <>
> Cc: Jonathan Corbet <>
> Cc: Michael Chan <>
> Cc: Bin Luo <>
> Cc: Saeed Mahameed <>
> Cc: Leon Romanovsky <>
> Cc: Ido Schimmel <>
> Cc: Danielle Ratson <>
> Cc: Shannon Nelson <>

Thanks Jake.  For ionic:
Acked-by: Shannon Nelson <>

Powered by blists - more mailing lists