>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.
I think, secure world has capability of writing to flash, mainly for secure variables. On x86, what I recall they have two partitions on flash , one is holding firmware and another is variables. And partition which has firmware is locked after end-of-dxe, due to this they have to reset to update the image. On ARM side, specifically on our platforms, we don’t have such scheme to partition flash. Then why not to write flash in context of OS instead of doing additional reset. Regards Udit > -----Original Message----- > From: boot-architecture <[email protected]> On > Behalf Of Grant Likely > Sent: Friday, April 26, 2019 4:28 PM > To: Bryan O'Donoghue <[email protected]>; boot- > [email protected] > Cc: nd <[email protected]> > Subject: [EXT] Re: StandaloneMM discussion > > Caution: EXT Email > > 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist > > s.linaro.org%2Fmailman%2Flistinfo%2Fboot- > architecture&data=02%7C01 > > > %7Cudit.kumar%40nxp.com%7Cffbc5c786c91432d9a2e08d6ca3634a6%7C686e > a1d3b > > > c2b4c6fa92cd99c5c301635%7C0%7C0%7C636918731493779757&sdata=% > 2FA38X > > UlqnPzYkHajk0EAanUvCMiOnOfz37M3nk%2Bqe4A%3D&reserved=0 > > _______________________________________________ > boot-architecture mailing list > [email protected] > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.linar > o.org%2Fmailman%2Flistinfo%2Fboot- > architecture&data=02%7C01%7Cudit.kumar%40nxp.com%7Cffbc5c786c91 > 432d9a2e08d6ca3634a6%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0% > 7C636918731493779757&sdata=%2FA38XUlqnPzYkHajk0EAanUvCMiOnOfz > 37M3nk%2Bqe4A%3D&reserved=0 _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
