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.
