On Fri, 26 Apr 2019 at 13:14, Udit Kumar <[email protected]> wrote: > >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. > > Agreed. this is a perfectly valid method. We do not intend to just mimic x86, we intend to provide a solution that can work in all cases AND take advantages of Arm architecture.
> 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 > -- 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
