On Fri, 26 Apr 2019 at 14:45, Bryan O'Donoghue bryan.odonoghue@linaro.org wrote:
On 26/04/2019 12:01, Francois Ozog wrote:
On Fri, 26 Apr 2019 at 12:36, Bryan O'Donoghue <bryan.odonoghue@linaro.org mailto:bryan.odonoghue@linaro.org> 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 firmwaredoes
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 [] beingoptional ?
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 ?
The UEFI implementer in U-Boot can implement the whole process of update in its context or just pass to OPTEE or use OPTEE for a limited set of things. The runtime service is just the interface. Implementation will be free. We will provide a reference implementation for a set of boards that may use some form of OPTEE. The StandAloneMM TA is the mandatory object (if you don't have dedicated secure storage) to deal with UEFI secure storage for UEFI secure variables. There may be additional TAs such as firmwareTPM or others.
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.
can you use EFIBootGuard that is used by CIP and with whom we also have
disccusions?
EFI variables, updated by a Linux agent is a nice fit.
bod