linux-kernel - New firmware-load case for the firmware subsystem?

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

Message-ID: <b9f07520-c5cb-927a-fba8-0f975c885f7d@intel.com>
Date:   Wed, 4 Aug 2021 17:23:14 -0700
From:   Russ Weight <russell.h.weight@...el.com>
To:     Luis Chamberlain <mcgrof@...nel.org>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "Moritz Fischer" <mdf@...nel.org>, "Wu, Hao" <hao.wu@...el.com>,
        "Xu, Yilun" <yilun.xu@...el.com>,
        "Gerlach, Matthew" <matthew.gerlach@...el.com>,
        Tom Rix <trix@...hat.com>,
        "lgoncalv@...hat.com" <lgoncalv@...hat.com>
Subject: New firmware-load case for the firmware subsystem?

Hi Luis,

I have been working on a driver to allow updates to an Intel FPGA PCIe card.
In a recent email exchange, it was suggested that I investigate whether
this functionality could be provided in the existing firmware subsystem. I
have been looking at the firmware subsystem. I don't think there is much
overlap between what I need to do and what is already provided. I would
appreciate your thoughts on the following.

For background information, this is the email thread I referred to:
https://marc.info/?l=linux-fpga&m=162810644009070&w=2

and this is the last submission of the driver in it's current form:
https://marc.info/?l=linux-fpga&m=162742505425902&w=2

In a nutshell, these are features that I believe are not currently in the
the firmware subsystem.

(1) Updates don't take place during driver probe / initialization. The
    updates need to be applied while the FPGA device is up and fully
    functional. FPGA image updates and firmware updates are stored to FLASH
    and do not take affect until the card is rebooted.

(2) Need an API to allow the user to initiate the update and specify
    the image file. The images are signed/authenticated files that are
    authenticated by the device using installed keys. Some image types
    are expected to be provided by the end-user. For example, the image
    file may contain a new Root Hash Entry for Partial Reconfigurations
    (which are under control of the end-user).

(3) We have one update case that can take up to 45 minutes. In order to be
    able to provide some sort of progress indication to the user, we would
    like to do the update in the context of a kernel worker thread, with
    progress status available through a user API.

I think I have the following options:

(1) Continue to develop an FPGA-specific image update driver

(2) Consider a more generic firmware update mechanism that others
    may be able to use.

(3) Consider integrating this functionality into the existing firmware
    subsystem.

Do you see any opportunity to share code? Do you think this functionality
would fit in the existing firmware subsystem?

Thanks,
- Russ