[PATCH 00/12] arm64: FF-A runtime transport for EFI variables

[Harsimran Singh Tungal]

On 2026-04-25 00:18 +0200, Heinrich Schuchardt wrote:
> Am 24. April 2026 19:31:39 MESZ schrieb Harsimran Singh Tungal <harsimransingh.tungal at arm.com>:
> >Hi all,
> >
> >This series adds FF-A runtime transport support so EFI variable runtime
> >services can communicate with the secure world after ExitBootServices().
> >It also extends tests, docs, and board configs to validate the runtime
> >path and keep boot‑time behavior aligned with the runtime flow.
> 
> Hello Harsiman,
> 
> Could you, please, explain the motivation for the series.
> 
> What is the overall architecture?
> 
> Please, describe how to set up a system on QEMU to test your development including the instructions for the secure world.
> 
> We would need a test in the CI using QEMU.
> 
> Best regards
> 
> Heinrich
> 
>
Hi Heinrich,

The motivation for the series is that, when EFI variables are backed by an
MM Secure Partition reached over FF-A, U-Boot can use that path during boot,
but after ExitBootServices() the normal FF-A/DM path is no longer suitable.
As a result, EFI runtime variable services can no longer reach the secure
partition. The goal of this series is to keep only the minimal FF-A transport
needed for EFI runtime variable services available after ExitBootServices().

The overall architecture is:

- During boot, the FF-A bus probes normally, discovers the U-Boot endpoint ID
  and the MM SP partition ID, and registers an ExitBootServices() callback.
- At ExitBootServices(), U-Boot copies the minimal FF-A state needed at
  runtime into resident runtime data and enables the runtime context.
- After that, EFI runtime variable operations
  (SetVariable/GetVariable/GetNextVariableName/QueryVariableInfo) use the
  runtime-safe path in efi_variable_tee.c, reuse the fixed FF-A shared buffer,
  perform range-based cache maintenance on that buffer only, and notify the
  MM SP using FF-A direct messaging.

So the runtime side is intentionally narrow: it keeps just enough FF-A support
for EFI runtime variables, rather than trying to preserve the full FF-A bus
or driver-model stack after ExitBootServices().

On testing, the current series adds sandbox DM tests for the FF-A runtime
helpers and EFI selftests for the runtime variable path, and my end-to-end
validation so far has been on Corstone-1000. I do not have a proper QEMU
setup with the corresponding secure-world/MM SP side packaged as part of this
series, so I cannot provide good QEMU instructions.

More details on building and running Corstone-1000 FVP can be found here:
https://corstone1000.docs.arm.com/en/latest/user-guide.html

Please let me know if this overall direction makes sense to you.

Regards
Harsimran Singh Tungal

> >
> >Changes in this series:
> >- Add EFI runtime-safe memset helper and FF-A runtime transport support.
> >- Implement FF-A runtime communication in the EFI variable TEE backend.
> >- Enable runtime variable operations and move helpers to avoid conflicts.
> >- Add sandbox runtime transport tests and metadata reuse.
> >- Extend EFI selftests for runtime variables and bootefi selftest config.
> >- Document the FF-A runtime transport and selftest behavior.
> >- Align boot‑time cache maintenance with the runtime path.
> >
> >Harsimran Singh Tungal (12):
> >  efi_loader: add runtime memset helper
> >  arm-ffa: add FF-A bus runtime support
> >  efi_loader: add FF-A runtime support in EFI variable TEE driver
> >  efi_loader: enable EFI runtime SetVariable()/GetVariable() using FF-A
> >    transport
> >  efi_loader: move runtime GetVariable() helpers to efi_variable.c
> >  corstone1000: enable bootefi selftest
> >  efi: selftest: add runtime variable tests with non-volatile storage
> >  test: dm: add sandbox FF-A runtime transport tests
> >  sandbox: ffa: share synthetic partition metadata via macros
> >  doc: arm64: document FF-A runtime path for EFI variables
> >  doc: bootefi: note two-phase runtime variables selftest
> >  efi_loader: align FF-A cache maintenance with runtime path
> >
> > arch/sandbox/include/asm/sandbox_arm_ffa.h    |  16 +-
> > configs/corstone1000_defconfig                |   3 +
> > doc/arch/arm64.ffa.rst                        |  92 ++-
> > doc/usage/cmd/armffa.rst                      |  11 +
> > doc/usage/cmd/bootefi.rst                     |  12 +
> > drivers/firmware/arm-ffa/Kconfig              |  11 +
> > drivers/firmware/arm-ffa/Makefile             |   4 +-
> > drivers/firmware/arm-ffa/arm-ffa-runtime.c    | 287 ++++++++
> > drivers/firmware/arm-ffa/arm-ffa-uclass.c     | 111 +--
> > drivers/firmware/arm-ffa/arm-ffa.c            |  16 +-
> > drivers/firmware/arm-ffa/ffa-emul-uclass.c    |  48 +-
> > include/arm_ffa.h                             |  16 +-
> > include/arm_ffa_priv.h                        |  24 +-
> > include/arm_ffa_runtime.h                     | 183 +++++
> > include/efi_loader.h                          |   3 +
> > lib/charset.c                                 |   2 +-
> > lib/efi_loader/efi_runtime.c                  |  21 +
> > lib/efi_loader/efi_var_common.c               |  24 -
> > lib/efi_loader/efi_variable.c                 |  24 +
> > lib/efi_loader/efi_variable_tee.c             | 686 +++++++++++++++++-
> > .../efi_selftest_variables_runtime.c          | 106 ++-
> > test/dm/Makefile                              |   3 +-
> > test/dm/ffa.c                                 |   6 +-
> > test/dm/ffa_runtime.c                         |  82 +++
> > 24 files changed, 1602 insertions(+), 189 deletions(-)
> > create mode 100644 drivers/firmware/arm-ffa/arm-ffa-runtime.c
> > create mode 100644 include/arm_ffa_runtime.h
> > create mode 100644 test/dm/ffa_runtime.c
> >
> 
>