On 26/04/2019 11:35, Bryan O'Donoghue 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 ?
We're talking about boot image authentication here (OS Loader, boot menu, other EFI applications), not firmware image updates. Boot image authentication can happily be handled in unpriviledged normal world code. However for firmware image updates to be secure they absolutely need to be authenticated by trusted code before being applied. Firmware image authentication will probably use a different key than anything in the PK, KEK, DB, or DBX variables. > > Is that the current POR ? > > 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. This flow works on Arm too, but only if the platform firmware implements UpdateCapsule() after ExitBootServices() [see below]. SBSA/SBBR platforms do this. It is optional on EBBR. There is renewed interest in this approach though if secureworld firmware has the capability of writing images while the OS is running as it would allow image updates to be performed in the background rather than taking the system down for a period of time. > 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 ? I don't think anyone is going down this path at the moment. If UpdateCapsule() doesn't work at runtime then the OS needs to use the capsule-update-on-disk method (see below). > A question then would it not also be possible to bypass capsule > submission in Linux ? On a device designed with security in mind, none of the images (BL31, BL32, or BL33) would be able to be updated by normal world code. Image updates would probably be written by BL32. U-Boot pass the images to BL32 However, On the SBCs we have today where firmware images are stored on eMMC or SD card there is nothing stopping Linux from completely overwriting/replacing/changing the firmware images, but the boot rom may refuse to execute the firmware image if it doesn't have the right signature (can protect against unsigned code, but cannot protect against rollbacks). > > #2 > Linux -> reboot -> BootROM -> [BL31],[BL32 TEE] -> u-boot > > with u-boot looking for say /boot/FirmwareUpdate.cap > > In the second case, there's no need from Runtime services is why I ask. This is the capsule-update-on-disk method. Confusingly this still uses UpdateCapsule() from the RuntimeServices table! The way UEFI is defined is there are 2 tables of function pointers: BootServices and RuntimeServices. Both are available before the call to ExitBootServices(), but only RuntimeServices are available after. Also, firmware may choose to stub out some/all RuntimeServices functions after ExitBootServices() is called if it is too difficult to implement. U-Boot currently stubs out most of the runtime services functions after ExitBootServices() is called. g. > > --- > bod > _______________________________________________ > boot-architecture mailing list > [email protected] > https://lists.linaro.org/mailman/listinfo/boot-architecture _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
