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/1JK00su6e7vt8lRfwSt2C9EuuzwcBHLyoLRRr...
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.