On 26/04/2019 12:01, Francois Ozog wrote:
On Fri, 26 Apr 2019 at 12:36, Bryan O'Donoghue
<[email protected] <mailto:[email protected]>> 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 ?
That shall be one of the few runtime services supported as well as
get/set variables.
Is that the current POR ?
Yes
Well - implementing the RunTime service in u-boot or TEE doesn't make
much difference from the use-case I'm looking at.
It's a positive that the model we are looking at is a runtime updating -
as opposed to a reset based model, which was a bit of a concern for me -
thinking about how long a Capsule would need to persist in memory
BootROM -> ATF/OPTEE -> uboot and then finally a jump to program the flash.
Of course as Udit pointed out, the reason x86 does a reset is because it
has to. SPI flash is locked before the DXE phase.
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.
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 ?
only for the untrusted parts. S-EL3 shall update or validate the updates.
OK.
Just to clarify then. For the runtime update model.
- u-boot will implement enough in RuntimeServices to enable
EFI variables
CapsuleUpdate
- OP-TEE/TA
Will aim to provide a similar set of functionality
But, you will be able to everything you need to do from what is being
implemented in u-boot.
The TA then is extra security sugar on top, giving a more secure version
of EFI variables and CapsuleUpdate ?
A question then would it not also be possible to bypass capsule
submission in Linux ?
In a different thread (EFIBootguard: do you follow this one too?),
someone proposed that in the context of A/B partitions, Linux software
agent updates a partition and the reboot cycle validates if it accepts.
There's a nearly identical proposal in the mix in ISG - with the missing
bit being - where is the A/B stuff stored and how is it updated.
EFI variables, updated by a Linux agent is a nice fit.
---
bod
_______________________________________________
boot-architecture mailing list
[email protected]
https://lists.linaro.org/mailman/listinfo/boot-architecture
