Please bear with [EXT] added in subject Tag, now a days outlook is adding this funny tag
-----Original Message----- From: boot-architecture boot-architecture-bounces@lists.linaro.org On Behalf Of Francois Ozog Sent: Friday, April 26, 2019 6:12 PM To: Ard Biesheuvel ard.biesheuvel@linaro.org Cc: Bryan O'Donoghue bryan.odonoghue@linaro.org; boot- architecture@lists.linaro.org; Grant Likely Grant.Likely@arm.com; nd nd@arm.com Subject: [EXT] Re: StandaloneMM discussion
Caution: EXT Email
On Fri, 26 Apr 2019 at 14:26, Ard Biesheuvel ard.biesheuvel@linaro.org wrote:
On Fri, 26 Apr 2019 at 12:58, Grant Likely Grant.Likely@arm.com 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 boot-architecture@lists.linaro.org 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 boot-architecture@lists.linaro.org 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 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%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 francois.ozog@linaro.org | Skype: ffozog _______________________________________________ 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%7Cba6be424a0e 14a5ab08008d6ca44bd0e%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0 %7C636918793915800061&sdata=BGeWRY5A4erpJzI8bwFxT3pemvvFVU2u ULoct91Yl5U%3D&reserved=0