Fit images and EFI_LOAD_FILE2_PROTOCOL

[Grant Likely]

On 06/10/2020 13:04, François Ozog wrote:
> As always, Ard made a good point, and I feel compelled to top post and 
> restate stuff.
> 
> Here is the supporting deck:
> https://docs.google.com/presentation/d/1JK00su6e7vt8lRfwSt2C9EuuzwcBHLyoLRRrdcYfVWY/edit?usp=sharing
> 
> We have two boot flows under consideration (not saying others are bad, 
> just to say they are on focus):
> A.1 typical distro (slide 2): <EFI firmware/ACPI> --> <shim> --> <grub> 
> --> Linux; Linux is here defined as the tuple {vmlinuz}, vmlinuz is 
> verified through EFI mechanism by either efi firmware or shim,  ACPI 
> tables are verified by firmware, initrd is not verified
> A.2 typical embedded (slide 3): <firmware/DT> -> Linux ; Linux is here 
> defined as the tuple {vmlinuz, initrd, dtb} that is folded into a FIT 
> and are verified via signature, it avoid errors/attacks about mixing 
> vmlinuz/initrd/dtb.
> 
> We want EBBR "equivalent" flows (Equivalent meaning with the same level 
> of security and accepting the weaknesses).
> B.1 typical distro (slide 4): <EFI firmware/DT> --> <shim> --> <grub> 
> --> Linux
> B.2 typical embedded (slide 5): <EFI firmware/DT> -> Linux
> 
> For B.1 to be equivalent to A.1, we need the DT to be authenticated 
> (ACPI is embedded in the firmware in A.1).

Current EBBR requires DT to be embedded in firmware by default. OS has 
option to replace it, but the firmware provided DT can be verified with 
the firmware image.

> For B2. to be equivalent to A.2, we need the DT and initrd to be 
> authenticated

I'm proposing an alternative to B2:
<EFI firmware/DT> -> FIT Shim (payload of kernel+initrd+dt) -> Linux

g.