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 boot-architecture-bounces@lists.linaro.org On Behalf Of Grant Likely Sent: Friday, April 26, 2019 4:28 PM To: Bryan O'Donoghue bryan.odonoghue@linaro.org; boot- architecture@lists.linaro.org Cc: nd nd@arm.com 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 boot-architecture@lists.linaro.org 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 boot-architecture@lists.linaro.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.lina... 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