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

[Michael Walle]

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.

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

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.

Thanks,
-michael