On 26.04.19 15:01, Francois Ozog wrote:
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.
If you don't have a storage that's only accessible from secure world, chances are *very* low you can safely access it from UEFI RTS because any access may conflict with the OS (clocks, pinctrl, device registers, window mappings, etc etc). So implementing anything but TA calls as U-Boot UEFI RTS is a waste of time for CapsuleUpdate IMHO.
For UEFI variables, I'm not 100% convinced we ever got to any other conclusion that the above. The main difference is that you *can* expose an in-memory cache of variables which only persist on reset. If you really have to :).
Alex