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]

Date:   Fri, 10 Jul 2020 11:55:05 +0530
From:   Vasundhara Volam <vasundhara-v.volam@...adcom.com>
To:     Jakub Kicinski <kubakici@...pl>
Cc:     Jacob Keller <jacob.e.keller@...el.com>,
        Netdev <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 Fri, Jul 10, 2020 at 5:56 AM Jakub Kicinski <kubakici@...pl> wrote:
>
> 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.
Yes, please go through the discussions happening on "[RFC v2 net-next]
devlink: Add reset subcommand." mail thread. I am waiting for Moshe
pachset for 'devlink dev reload' before further efforts.


>
> > * '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..