On Fri, 26 Apr 2019 at 12:58, Grant Likely <[email protected]> wrote: > > 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. >
I disagree. Firmware *updates* need to be authenticated to whichever agent is in charge of writing the flash. It is perfectly reasonable for the non-secure firmware to be in charge of this, e.g., before the flash is locked down, just like the non-secure firmware is 'trusted' in terms of booting chain of trust all the way into the OS. This is the model that x86 uses on UEFI systems. Whether the secure component of that firmware update can actually *boot* is an entirely different matter, and so a firmware update payload will typically consist of a signed payload (for execution) in a signed container (for updating) > > > > 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 _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
