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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200709171913.5b779cc7@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Date:   Thu, 9 Jul 2020 17:19:13 -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,  9 Jul 2020 14:26:52 -0700 Jacob Keller wrote:
> The flash update for the ice hardware currently supports a single fixed
> configuration:
> 
> * Firmware is always asked to preserve all changeable fields
> * The driver never allows downgrades
> * The driver will not allow canceling a previous update that never
>   completed (for example because an EMP reset never occurred)
> * The driver does not attempt to trigger an EMP reset immediately.
> 
> This default mode of operation is reasonable. However, it is often
> useful to allow system administrators more control over the update
> process. To enable this, implement devlink parameters that allow the
> system administrator to specify the desired behaviors:
> 
> * 'reset_after_flash_update'
>   If enabled, the driver will request that the firmware immediately
>   trigger an EMP reset when completing the device update. This will
>   result in the device switching active banks immediately and
>   re-initializing with the new firmware.

This should probably be handled through a reset API like what
Vasundhara is already working on.

> * 'allow_downgrade_on_flash_update'
>   If enabled, the driver will attempt to update device flash even when
>   firmware indicates that such an update would be a downgrade.
> * 'ignore_pending_flash_update'
>   If enabled, the device driver will cancel a previous pending update.
>   A pending update is one where the steps to write the update to the NVM
>   bank has finished, but the device never reset, as the system had not
>   yet been rebooted.

These can be implemented in user space based on the values of running
and stored versions from devlink info.

> * 'flash_update_preservation_level'
>   The value determines the preservation mode to request from firmware,
>   among the following 4 choices:
>   * PRESERVE_ALL (0)
>     Preserve all settings and fields in the NVM configuration
>   * PRESERVE_LIMITED (1)
>     Preserve only a limited set of fields, including the VPD, PCI serial
>     ID, MAC address, etc. This results in permanent settings being
>     reset, including changes to the port configuration, such as the
>     number of physical functions created.
>   * PRESERVE_FACTORY_SETTINGS (2)
>     Reset all configuration fields to the factory default settings
>     stored within the NVM.
>   * PRESERVE_NONE (3)
>     Do not perform any preservation.

Could this also be handled in a separate reset API? It seems useful to
be able to reset to factory defaults at any time, not just FW upgrade..