linux-kernel - [RFC PATCH v2 0/1] firmware: smccc: Add support for Live Firmware Activation (LFA)

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

Message-Id: <20250926123145.268728-1-salman.nabi@arm.com>
Date: Fri, 26 Sep 2025 12:31:44 +0000
From: Salman Nabi <salman.nabi@....com>
To: mark.rutland@....com,
	lpieralisi@...nel.org,
	sudeep.holla@....com,
	andre.przywara@....com
Cc: linux-arm-kernel@...ts.infradead.org,
	linux-kernel@...r.kernel.org,
	linux-coco@...ts.linux.dev,
	vsethi@...dia.com,
	sdonthineni@...dia.com,
	vwadekar@...dia.com,
	chao.gao@...el.com,
	ardb@...nel.org
Subject: [RFC PATCH v2 0/1] firmware: smccc: Add support for Live Firmware Activation (LFA)

Hi,

This patch addresses some feedback from the previous RFC, and fixes and
improves some shortcomings discovered during internal review:
There is now a new sysfs file to waive the kernel's CPU rendezvous
requirement, if administrators are sure that the firmware's brief downtime
has no effect on the kernel's drivers. Also the firmware images are now
handled in a linked list, as this provides more flexibility for upcoming
changes. For more details, see the original cover letter, the changelog
below and the patch's commit message. We are still looking for feedback,
also from other architectures, on the best userland interface.

=====================================================================

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?

=====================================================================

v1...v2:
 - added forcce_cpu_rendezvous hook for skipping cpu rendezvous for
   firmware components that supports it.
 - changed the static firmware images array with a dynamic linked list.
 - the activation pending flag is retrieved directly from the lfa agent
   for an up-to-date information.
 - added a mapping of LFA error codes to human-readable strings.
 - kernel error codes changed to more appropriate ones
 - comment fix in call_lfa_activate()
 - the "bitfields" name in variables has been refactored to an
   appropriate "image_flags".
 - change image_flags variable datatype to u32 from an int

Many thanks
Salman Nabi

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 | 455 ++++++++++++++++++++++++++++++++
 3 files changed, 463 insertions(+)
 create mode 100644 drivers/firmware/smccc/lfa_fw.c

-- 
2.25.1