Please bear with [EXT] added in subject Tag, now a days outlook is adding this funny tag
> -----Original Message----- > From: boot-architecture <[email protected]> On > Behalf Of Francois Ozog > Sent: Friday, April 26, 2019 6:12 PM > To: Ard Biesheuvel <[email protected]> > Cc: Bryan O'Donoghue <[email protected]>; boot- > [email protected]; Grant Likely <[email protected]>; nd > <[email protected]> > Subject: [EXT] Re: StandaloneMM discussion > > Caution: EXT Email > > 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. Does *freely* means, OS is updating partition B , and at next boot if firmware finds B partition valid, it will use those images ?? > > > > > > > > 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%2F > > > > lists.linaro.org%2Fmailman%2Flistinfo%2Fboot-architecture&data > > > > > =02%7C01%7Cudit.kumar%40nxp.com%7Cba6be424a0e14a5ab08008d6ca44bd > 0e > > > > > %7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636918793915790056 > &a > > > > > mp;sdata=vtQUGIyZnZKzeBbqbKGKqjEJY0vfCSSHDU8MD9l2xpo%3D&reserv > > > > ed=0 > > > > > > _______________________________________________ > > > boot-architecture mailing list > > > [email protected] > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fli > > > sts.linaro.org%2Fmailman%2Flistinfo%2Fboot-architecture&data=02% > > > > 7C01%7Cudit.kumar%40nxp.com%7Cba6be424a0e14a5ab08008d6ca44bd0e%7 > C686 > > > > ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636918793915800061&s > data > > > > =BGeWRY5A4erpJzI8bwFxT3pemvvFVU2uULoct91Yl5U%3D&reserved=0 > > _______________________________________________ > > 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%7Cba6be424a0e14a5ab08008d6ca44bd0e%7C686 > ea1d3b > > > c2b4c6fa92cd99c5c301635%7C0%7C0%7C636918793915800061&sdata=B > GeWRY5 > > A4erpJzI8bwFxT3pemvvFVU2uULoct91Yl5U%3D&reserved=0 > > > > > -- > 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.linar > o.org%2Fmailman%2Flistinfo%2Fboot- > architecture&data=02%7C01%7Cudit.kumar%40nxp.com%7Cba6be424a0e > 14a5ab08008d6ca44bd0e%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0 > %7C636918793915800061&sdata=BGeWRY5A4erpJzI8bwFxT3pemvvFVU2u > ULoct91Yl5U%3D&reserved=0 _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
