Hi,

(please feel free to add people interested on this from the x86 side
as you see fit)

this is a proposal for a driver for the Arm Live Firmware Activation (LFA)
specification[1]. LFA provides an interface to allow "activating" firmware
updates without a reboot.
In contrast to Intel's TDX [2] approach (which seems only concerned about
some confidential computing related firmware blob), and even OCP's
"impactless" updates[3], the Arm approach just lists a number of
"activatable" firmware images, and does not limit their scope. In
particular those updates can (and will) be for firmware bits used by the
application processors (which OCP seems to rule out), including runtime
secure firmware (TF-A/BL31), confidential compute firmware, and
potentially even UEFI runtime firmware.
Initially we have the whole chain demoing the Arm Confidential Computing
firmware (RMM) update, which is conceptually the same as Intel's TDX
proposal.

So our design approach is to create a directory under /sys/firmware, and
just list all images there, as directories named by their GUID.
Then the properties of each image can be queried and the activation
triggered by the sysfs files inside each directory. For details see the
commit message of the patch.
This is admittedly a somewhat raw interface, though even in that form
it's good enough for testing. Eventually I would expect some fwupd
plugin to wrap this nicely for any admins or end users.

The purpose of this RFC is to get some feedback on the feasibility of
this interface, and to understand how this would relate to the other two
approaches (TDX + OCP "impactless" updates).

- Are GUID named directories under /sys/firmware/lfa a good idea?
- Shall all three approaches be unified under a common kernel/userland
  sysfs interface? Or can we live with separate interfaces, given the
  different scopes, and unify this in userland, for instance via fwupd
  plugins?

Thanks,
Andre

[1] https://developer.arm.com/documentation/den0147/latest/
[2] https://lore.kernel.org/all/20250523095322.88774-1-chao.gao@intel.com/
[3] https://www.opencompute.org/documents/hyperscale-cpu-impactless-firmware-updates-requirements-specification-v0-5-2025-05-22-pdf

Salman Nabi (1):
  firmware: smccc: Add support for Live Firmware Activation (LFA)

 drivers/firmware/smccc/Kconfig  |   7 +
 drivers/firmware/smccc/Makefile |   1 +
 drivers/firmware/smccc/lfa_fw.c | 411 ++++++++++++++++++++++++++++++++
 3 files changed, 419 insertions(+)
 create mode 100644 drivers/firmware/smccc/lfa_fw.c

-- 
2.25.1

On Wed, Jun 25, 2025 at 03:27:21PM +0100, Andre Przywara wrote:
> Hi,
> 
> (please feel free to add people interested on this from the x86 side
> as you see fit)
> 
> this is a proposal for a driver for the Arm Live Firmware Activation (LFA)
> specification[1]. LFA provides an interface to allow "activating" firmware
> updates without a reboot.
> In contrast to Intel's TDX [2] approach (which seems only concerned about
> some confidential computing related firmware blob), and even OCP's
> "impactless" updates[3], the Arm approach just lists a number of
> "activatable" firmware images, and does not limit their scope. In
> particular those updates can (and will) be for firmware bits used by the
> application processors (which OCP seems to rule out), including runtime
> secure firmware (TF-A/BL31), confidential compute firmware, and
> potentially even UEFI runtime firmware.
> Initially we have the whole chain demoing the Arm Confidential Computing
> firmware (RMM) update, which is conceptually the same as Intel's TDX
> proposal.
> 
> So our design approach is to create a directory under /sys/firmware, and
> just list all images there, as directories named by their GUID.
> Then the properties of each image can be queried and the activation
> triggered by the sysfs files inside each directory. For details see the
> commit message of the patch.
> This is admittedly a somewhat raw interface, though even in that form
> it's good enough for testing. Eventually I would expect some fwupd
> plugin to wrap this nicely for any admins or end users.
> 
> The purpose of this RFC is to get some feedback on the feasibility of
> this interface, and to understand how this would relate to the other two
> approaches (TDX + OCP "impactless" updates).
> 

Thanks for the details and I agree we need opinions from x86 community
if possible but definitely from cloud/hyperscale community using these
user interfaces ? While x86 and Arm may provide its own user interface,
are hyperscale community happy with that ? I briefly read the unified
(arch agnostic) requirements specification [3] but will there be a
requirement to have a unified user interface from the OS ?

We don't want to define something Arm specific to just abandon it quickly
if and when hyperscale community comes back with such a request for unified
user interface.

I am not against having Arm specific interface, just getting clarification
in terms of requirements even before diving into technical review of the
patch here.

Anyone from hyperscale community ? Please provide directions here.

-- 
Regards,
Sudeep