On Fri, 26 Apr 2019 at 14:26, Ard Biesheuvel <[email protected]> wrote:
> 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) > > Agreed with the condition that the agent writing directly the new firmware cannot update the chain of trust that led to the update. So if we have an A/B partition (here partition is used in a broader sense than a disk partition or MMC partition), booted on partition A, the partition A is locked. partition B can be freely updated, including trusted software, providing that next boot partition A will deal with validating partition B. > > > > > > 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 > -- François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* T: +33.67221.6485 [email protected] | Skype: ffozog _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
