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

[Ilias Apalodimas]

Hi Michael

On Tue, 19 Dec 2023 at 14:47, Michael Walle <mwalle at kernel.org> wrote:
>
> Hi Mark,
>
> >> > 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.
>
> I know. Last time I checked CentOS (or was it Ubuntu?) tried to
> set EFI variables and the installer just failed. Might be fixed now,
> though.

It's not. The error message is less scary in distros nowadays, but
setting the variable for Boot0000 is still not working. That being
said I have a plan to fix it for variables stored in a file, that's
why we standardized the efi variable format in EBBR.

>
> > 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.
>
> Thats clear.
>
> >> 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?

Depends by 'not exposed'. And keep in mind that with a simple SPI
flash you also have to worry about easy hardware attacks. E.g. someone
replaces your SPI flash with his version of authenticated EFI
variables.

We have patches on the ML adding variable support to SPI a SPI flash,
but excluding authenticated variables. [0]

> >
> > 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.
>
> Fair point, but I was thinking about the ls1028a for example, where - if
> I remember correctly - there was one dedicated i2c controller in a sense
> of isolation, probably to use with a secure OS. Also there is no dynamic
> clocking.
>
> So, technically it should be possible, even with a low overhead, like no> device model etc, which could reside in the efi os services. Just
> testing
> the waters here, not that I'm interested in adding support for that in
> u-boot. Just a bit concerned that it (EFI variables) will only work with
> a full stack (tf-a, optee) in the future.
>
> > * 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.

That would be an EEPROM dedicated to the secure world. At some point,
I got involved with an EDK2 implementation for supporting EFI
variables on a SolidRun honeycomb. We even fixed SetVariableRT and we
run the whole thing via OP-TEE (just like we do for RPMB in U-Boot).
So this (minus the physical attacks) is quite secure, because even the
code running the crypto checks for authenticating variables, runs
isolated in the secure world.

It's been a while, but IIRC StMM has FVBs (firmware block protocols)
in EDK2 parlance. We have StMM FVBs for RPMBs and EEPROMs and we can
launch StMM from OP-TEE. Adding runtime variable support for the RPMB
is close to impossible if you want to adhere to the EFI spec, but for
it's doable for the EEPROM.

Ping me on IRC if you start adding support, I can help.

>
> Sure. I excluded any secure stuff. But, with that i2c controller i was
> talking about earlier, it should be possible to mark it as EL3 access
> only.

Yes, there was a slight implication. NXP some had timer on that I2C or
something, but it's been too long to remember the details...

>
> Thanks,
> -michael

Thanks
/Ilias

[0] https://lore.kernel.org/u-boot/20231126220836.374956-2-i@shantur.com/