On Fri, 31 May 2019 at 17:33, Grant Likely Grant.Likely@arm.com wrote:
On 27/05/2019 10:05, Ilias Apalodimas wrote:
Hi Udit,
Hi Ilias
-----Original Message----- From: Ilias Apalodimas ilias.apalodimas@linaro.org Sent: Friday, May 24, 2019 9:57 PM To: Udit Kumar udit.kumar@nxp.com Cc: boot-architecture@lists.linaro.org; Varun Sethi V.Sethi@nxp.com Subject: Re: [EXT] Securing the boot flow in U-Boot
Caution: EXT Email
Hi Udit,
What do you think?
Here we are talking about image signing and image validation. I am not sure, what are your plan to make keys data base (platform key, KeK and DBs) secure while writing. AFAIU, This is one of requirement of secure uefi that these secure variable
should be written in MM mode. The plan on that is run stMM as an OP-TEE TA. This will allow us to run StMM + fTPM simultaneously. The current plan is to support UEFI specs on U-Boot without having secure variable storage. That one is our next step.
May be I am asking too early about your next step
Indeed :) We'll try to have the UEFI secure boot spec in u-boot first, *without* storing the variables in a secure storage. Once we complete this we can start planning the secure part of the varibles.
A bit of history on this. One of the things we are going to try is split U-Boot ENV and UEFI variables. By decoupling those, storing the variables in a different storage should be straightforward (or at least a lot easier than it is today).
Where you see flash driver sitting, Possible options I see, 1/ In OP-TEE and StMM is making sys-call to access it 2/ in TFA (EL3) itself and stMM is making smc calls 3/ OP-TEE is doing sort of mmap to flash controller area and driver is residing in Sec-EL0 itself
All three sound valid. This also depends on the hardware design as well. This is too soon for us, if anyone else has any suggestions it might be a good idea to sum those up in a new thread?
On systems with normal-world mapped eMMC/UFS with RPMB: Option 1
- trusted app needs to coordinate with normal world firmware & OS
- The trusted app will prepare and sign RPMB update transactions and
depend on a supplicant in the normal world to perform the transaction. U-Boot will need an implementation of the optee supplicant.
Just an update, U-Boot already have optee supplicant support for RPMB storage access. Have a look here [1].
[1] https://github.com/u-boot/u-boot/blob/master/drivers/tee/optee/rpmb.c
-Sumit
Linux already has one.
On systems with secure-world mapped secure storage: Option 3
- The trusted app doesn't need to coordinate with the normal world.
- It can directly write to storage.
Option 2 is not an option because we don't want device drivers (ie, for secure storage devices) in EL3 TFA. It is supposed to be as small as possible.
g. _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture