Adding EFI runtime support to the Arm's FF-A bus

[Mark Kettenis]

> From: Michael Walle <mwalle at kernel.org>
> Date: Tue, 19 Dec 2023 11:11:24 +0100
> 
> Hi Heinrich,

Hi Michael,

> > Any runtime device drivers for variable storage should not be in the
> > U-Boot runtime but live in the secure world (e.g. OP-TEE) FF-A is the
> > new ARM protocol for talking to the secure world and hence fits into
> > the picture.
> 
> What if I just want a simple embedded boot stack where I don't
> want any secure world and just want to be able to boot a COTS linux
> distribution via EFI?

That already works for many Linux distros.  As long as the distro
installs the appropriate BOOTxxx.EFI file you don't actually need to
set any EFI variables for the OS to boot.  It can't get any simpler
than that.  Of the main Linux distros it seems that only Debian
doesn't do this.  Someone should probably lobby Debian to do this as
well as it would mean that Debian would just work on an EBBR compliant
system.

Things get more complicated if you want to install multiple OSes.
Then having EFI variable support makes things a lot more
straightforward.

And of course EFI secure boot needs EFI variable support as well (with
proper support) for authenticated EFI variables.  But IMHO that no
longer falls into "simple embedded boot stack" territory.

> Assuming, that there might be a simple dedicated EEPROM to store the
> variables which is not exposed to linux, is that something which would
> be rejected by u-boot mainline now?

Not necessarily.  But such an approach will have limitations:

* Completely hiding the EEPROM from the OS may be hard.  Even if you
  have a dedicated SPI controller for the EEPROM things like the SPI
  bus clock or power domains may still be under OS control.

* It is not possible to properly implement authenticated variables for
  secure boot if the EEPROM and associated hardware is just removed
  from the device tree but still accessable to the OS.  An
  implementation that pretends the variables are "secure" will
  probably be rejected.

Cheers,

Mark