GRUB & Secure Boot

[Kekun]

Endless OS’s GRUB patches should be carried forward, which includes adding OSTree/BLS support, automatic silent/verbose boot control, etc.

This will need the kernel image to be signed via API calls to the Endless AWS infrastructure (otherwise GRUB will refuse to boot it).

Endless OS’s shim (signed by Microsoft) also needs to be shipped. It would be useful to figure out whether future shim work should be built within GNOME OS (then sent to MS for signature) or if we should build separately and the OS build side just works with a fixed binary.

[dsd]

shim signed binary can be found in here: https://sources.endlessm.com/debian/pool/core/s/shim-signed/shim-signed_15%2Bdev16.b59aab6-7endless1.tar.gz

For that shim to boot EOS, grub and kernel need to be signed with Endless's key.

Currently this is done by eos-sb-signer processing Debian binary packages and respinning them with a signed variant, which eos-ostree-builder then includes in the ostree.

But eos-sb-signer also offers a HTTP API which can sign things "on demand" which is presumably more appropriate here. It's used for signing the PAYG boot blob and hopefully can be used (or easily adapted) for signing grub and kernel.

[dsd]

That's the wrong shim, I wonder why our sources site is out of date (@dbnicholson).

The right signed shim is here: https://github.com/endlessm/shim-review/releases/tag/endless-shim-x64-20240822

Thanks for the info! The BuildStream sandbox blocks network access, so we can't run the commands from https://github.com/endlessm/eos-ostree-builder/blob/master/hooks/os/86-sign-payg-image in any of the existing element plugins like 'manual' or 'script'.

What we can do is write our own element plugin. I don't know of any existing plugin that stages its input, passes it through a remote API, and then outputs the result. It would be good to have an example to copy from. A good reference might be the tar element plugin from buildstream-plugins-community, which passes its input through the Python tarfile module. The BuildStream Plugin API reference is also useful here.

We also will need a way to adapt this for local development where (I'm guessing) the signing API won't be available.

Roughly scoping this, the work is:

• Write a endless_sb_signer buildstream element plugin that calls https://sb-signer.endlessm-sf.com/api/sign, using the 86-sign-payg-image hook as an example.
• Add an eos/signed-kernel.bst element of kind endless_sb_signer that produces a signed kernel, and add that in the ostree (eos/repo.bst) at the standard location.
  • EOS7 already has a kernel, built from components/linux.bst, with its config in files/linux/fdsdk-config.sh.
• Add an eos/grub.bst element built from the master branch of https://github.com/endlessm/grub
  • Initial PR at: Initial build of GRUB #74
• Ship the pre-existing shim binary
• Testing images built with eos-image-builder:
  • Deploy to a machine that has "Secure boot" enabled, and check the image boots
  • Verify that unsigned kernels do not boot

Notes, risks, depenendencies:

• We can't sign or boot any images until Make the EOS7 ostree work with eos-image-builder #13 is underway
• It's not yet clear how the kernel will be passed to eos-image-builder: this could be done separately to buildstream, in which case the signing could happen outside buildstream as well and we wouldn't need a custom plugin
• The signing API hasn't been used to sign kernels before, and may need changes for that to work
  • Can be tested now, see below
• Signing is probably only possible in CI, local development needs handling somehow too
• If we can only produce signed images in CI, there could be a long cycle time for this task, as each change implies building, downloading and deploying a new multi-GB signed image.
  • Perhaps defining a smaller eos-minimal system during testing would help here

[dsd]

It's not yet clear how this kernel will be passed to eos-image-builder

Just place it in the ostree at the standard location

We can't sign or boot any images until #13 is underway

As one step in this direction you can check the kernel signature by:

1. Do the required work to get the kernel signed and committed to the ostree as above
2. Install current eos development image
3. Enable secure boot
4. Boot and switch branch to eos7
5. Reboot

--> if kernel signature is correct, the system will boot. Otherwise you will get a security violation error.

[dbnicholson]

That's the wrong shim, I wonder why our sources site is out of date (@dbnicholson).

Because sources never got updated to do anything past EOS 3 since it was essentially replaced by the public package repo at deb.endlessos.org. I had plans to merge them in https://phabricator.endlessm.com/T35714. The current source package is https://deb.endlessos.org/debian/pool/core/s/shim-signed/shim-signed_15.8-1~deb12u1endless2.tar.gz.