On 26/04/2019 12:01, Francois Ozog wrote:
On Fri, 26 Apr 2019 at 12:36, Bryan O'Donoghue <bryan.odonoghue@linaro.org mailto:bryan.odonoghue@linaro.org> wrote:
On 26/04/2019 10:29, Ilias Apalodimas wrote: >> I’d rather see Secure Boot image authentication implemented generically for all u-boot platforms, even when secure world variable updates are not available. > Akashi and Sughosh already have code on that. It's not 100% complete or tested > yet, but the basic concept works. Is that to say that u-boot will provide, Runtime services for EFI capsule update ?That shall be one of the few runtime services supported as well as get/set variables.
Is that the current POR ?Yes
Well - implementing the RunTime service in u-boot or TEE doesn't make much difference from the use-case I'm looking at.
It's a positive that the model we are looking at is a runtime updating - as opposed to a reset based model, which was a bit of a concern for me - thinking about how long a Capsule would need to persist in memory BootROM -> ATF/OPTEE -> uboot and then finally a jump to program the flash.
Of course as Udit pointed out, the reason x86 does a reset is because it has to. SPI flash is locked before the DXE phase.
Maybe its a stupid question but, on x86 the way this works is you submit a capsule to the EFI runtime service, reboot and the EFI firmware does your update. On Arm then the flow is #1 Linux capsule update -> reboot -> BootROM -> [BL31],[BL32 TEE] -> u-boot and u-boot performs the update ? The bracketed items [] being optional ?only for the untrusted parts. S-EL3 shall update or validate the updates.
OK.
Just to clarify then. For the runtime update model.
- u-boot will implement enough in RuntimeServices to enable EFI variables CapsuleUpdate
- OP-TEE/TA Will aim to provide a similar set of functionality
But, you will be able to everything you need to do from what is being implemented in u-boot.
The TA then is extra security sugar on top, giving a more secure version of EFI variables and CapsuleUpdate ?
A question then would it not also be possible to bypass capsule submission in Linux ?In a different thread (EFIBootguard: do you follow this one too?), someone proposed that in the context of A/B partitions, Linux software agent updates a partition and the reboot cycle validates if it accepts.
There's a nearly identical proposal in the mix in ISG - with the missing bit being - where is the A/B stuff stored and how is it updated.
EFI variables, updated by a Linux agent is a nice fit.
--- bod