[RFE] Support Secure Boot

[jepio]

Current situation

Flatcar currently does not support Secure Boot. We use a really old fork of shim and grub, and our artifacts are not signed in a way that works on machines with official UEFI CA keys.

Impact

Users can't run UEFI with Secure Boot enabled. This doesn't only affect bare metal installs but also some VMs (e.g. Azure Trusted Launch https://azure.microsoft.com/en-us/blog/announcing-preview-of-azure-trusted-launch-for-virtual-machines/).

Ideal future situation

Flatcar images contain EFI boot firmware signed with official UEFI CA keys, which make them compatible with Secure Boot on default provisioned UEFI firmware.

Implementation options

We still have https://github.com/kinvolk/flatcar-scripts/blob/main/image_inject_bootchain around. Our grub and kernel binaries are signed for secure boot but only with a dev key. We'll need to:

• upgrade grub (with our patches - I believe most are obsolete)
• upgrade shim
• set up signing infrastructure with an offline CA key, and an online signing key
• follow https://github.com/rhboot/shim-review to get a shim binary with our CA certificate signed
• set up a pipeline to sign grub and kernel and inject them into release artifacts

Additional information

[ Please Add any information that does not fit into any of the above sections here ]

[pothos]

I think we also need to change the way we use the grub.cfg config file on the OEM partition to read in variables. Maybe we can reduce this to a OEM file that we parse for some OEM ID and inside the trusted GRUB configuration then check against this value to set the desired variables.

[saulshanabrook]

Hello! I am trying to install flatcar linux on my home PC. I am getting a "Secure Boot Violation: Invalid signature detected. Check Secure Boot Policy in Setup", after using the flatcar-install to install on the hard disk. Is this because I flatcar does not support secure boot?

[jepio]

@saulshanabrook
Correct, secure Boot is not supported (our EFI binaries are not signed).

[joshenders]

I am correct in assuming that this PR along with some CA/signing infra changes you pointed out would resolve this issue?

[jepio]

Yes. The real work will be the CA/signing infra to get our shim trusted by the official UEFI CA.

[aw042]

Will secure boot support come after Flatcar finishes its ideal implementation of systemd-boot? I only just got a grasp on how secure boot works today (PK, KEK, db, dbx) and a small glimpse of what seems like a stringent process of approval. I would think at least the bootloader situation (shim -> systemd-boot) should be pretty well cemented before working through the mainstream UEFI signature approval process.

Resources:

https://techcommunity.microsoft.com/blog/hardwaredevcenter/updated-uefi-signing-requirements/1062916

https://github.com/rhboot/shim/wiki/reviewer-guidelines

There is no rush. I’m just trying to get a gauge of how prioritized this is. I’m hoping Flatcar becomes what I use for a lot, but without secure boot I’m leaning towards using other operating systems on bare metal and Flatcar in VMs which is okay, just I would love to manage an immutable fleet of Flatcar machines running Kubernetes clusters and minimizing downtime with Nebraska. Some people say I don’t have to worry about secure boot and that it’s not actually that secure, but I would like to see it because I think it carries some enterprise legitimacy with its signature approval process.

Thank you for all you have contributed so far, and congratulations on being accepted as a CNCF incubating project!

[jepio]

Work for secure boot support is in the end phases, we're going to be submitting the shim (together with our signing process and boot chain) for review in the coming weeks. This is not coupled to switching to systemd-boot, it will be based on the existing grub based boot process.

Here are some PRs if you're interested:

• Merge the Dockerfile for reproducible builds shim-review#1
• Add the infrastructure for shim signing & aarch64 support scripts#2292 (this one is being split up into individual PRs that are getting merged).