On Tue, Dec 19, 2023 at 01:47:07PM +0100, Michael Walle 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.
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.
I would fully expect us to continue to support the case you're describing. It just may have limitations or as you describe implementation work needing to be done to support handling security differently. But it should (*cough*) be abstracted such that it's possible to do so.