Hi Udit,
Continuing the discussions we had on securing the boot flow and OS as much as possible, we came up with the following idea.
We are currently sorting out what's needed to add UEFI Secure Boot in U-Boot.
I believe you are planning to support as UEFI specs [Chapter 31, UEFI spec 2.7]
Yes you are right
This will cover the next payload (shim/grub2/shim depending on board needs).
In order to provide better overall security for the OS we'll need to at least verify DTB (if provided externally), initramfs and kernel modules.
- For the kernel modules we can use kernel module signing facilities [1]
- In case someone wants to provide an external DTB, we can use FIT images
to secure that. The FIT images will contain the DTB(s) we need. Those will only be used if the authentication process succeeds. This will allow us to verify DTBs without introducing any new functionality to U-Boot. 3. We need to verify initramfs as well. This can be accomplished in various ways. Packing kernel + initramfs or using dm-verity are the two obvious ones but we are open to suggestions.
This also makes the development process for LEDGE pretty clear. We'll have to add UEFI Secure Boot implementation on U-Boot *only* since the rest of the functionality can be achieved with the existing code (minor adjustments might be needed though).
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.
Thanks /Ilias