Creating custom image based on UC20

Hi,

I’m looking at creating a custom image for deployment, but based on UC20. Initially just locally testing, but will be using a Brand Store eventually. We are particularly interested in the FDE in combination with a TPM2 device.

Trying everything in stages, I have so far:

Although the final test image built fine, it does not finish installing properly on a test system with a TPM2 device [ where all the previous test images installed ok with FDE ].

After initial boot and setup [ including the checks for Secure Boot enabled and TPM available etc ], it reboots. On reaching target Basic System it then moves onto mounting ubuntu-boot, ubuntu-seed and finally on mounting ubuntu-data-enc there is a prompt for a recovery key:

Please enter the recovery key for disk /dev/disk/by-label/ubuntu-data-enc: (press TAB for no echo)

…as I don’t have any input, it eventually times out with:

[FAILED] Failed to start the-tool.service.

The image works fine in a VM without a TPM device.

Any idea what the issue could ?

Thanks in advance,
Just

Are you building your own kernel snap as well?

No, I want to avoid modifying the kernel snap if possible, the only snap I am modifying is the gadget snap [ although so far it is only very light modification ]. This is because I want to try and take advantage of Secure Boot without needing to sign anything ourselves if possible.

Just to try and rule out a bug around FDE if the image is grade dangerous , I just tested with http://cdimage.ubuntu.com/ubuntu-core/20/dangerous-edge/20200915/ubuntu-core-20-amd64.img.xz , seems to install fine.

I have identified the source of the issue - but I don’t yet know the underlying reason, hopefully one of the Devs here can fill in gaps.

With my debugging, I reached the point where it really was only the contents of the gadget snap that differed. So I tried extracting the contents of mine and the published pc snap, and diffed them. The differences included some metadata [ like snap name and description etc ], but also the grub and shim executable. That got me thinking …

As I noted in my initial post, I had to modify the gadget snap so that it built without error. I linked to the details of that here: https://github.com/snapcore/pc-amd64-gadget/issues/49

So, I tried replacing the grubx64.efi in my snap with the one from the published snap. Re-created the squashfs image, the re-built the uc20 image. Same issue.

Then I tried the same process, but with replacing the shim.efi.signed in my snap with the one from the published snap. That new image worked !

In the snap, shim.efi.signed is just a copy of shimx64.efi.dualsigned from the shim-signed deb package. Please note, shimx64.efi.dualsigned is not in the stock 20.04 package, it only seems to be in the 20.10 package.

I have two primary questions:

  • Why do I need the dual-signed shim for this to work properly with FDE ?
  • How do I include the dual-signed shim in the build ?

For the build related issue, I’m using the default multipass approach. How do I make that process include the package I need, do I have to switch the build multipass instance to be 20.10 somehow, or somehow fiddle the apt sources, or something else ?

Thanks in advance,
Just

Ping @xnox for more information about the dual-signed shim, but in the meantime I can advice what we do for tests locally while working on uc20 itself.

If all we need to change is something in the gadget.yaml like defaults or connections, we will just unpack the upstream pc gadget snap (downloaded from the 20/edge channel) and modify that file and repack the rest of the as-is (including the grub and shim files).

If however we need to also change the kernel or something in the initramfs, we will end up needing to re-sign the kernel with snakeoil keys from the ubuntu-core-initramfs package (which comes from the snappy-dev/image PPA), then resign shim specifically in the gadget snap with snakeoil keys as well. Then finally, we need to switch the device to trust the snakeoil keys, which for a VM involves changing the OVMF vars file to OVMF_VARS.snakeoil.fd instead of the normal Microsoft keys version with @ OVMF_VARS.ms.fd. If you are booting/testing on a real device then you may want to enroll the snakeoil keys to your device’s firmware (details depend on the UEFI/motherboard vendor), but note that if this is a production device then enrolling the snakeoil keys will allow any attacker to bypass secureboot on that machine then, so only do that for development purposes.

Thanks for info @ijohnson

For the time being I have added override-stage to grub-prepare that wgets shim-signed_1.43+15+1552672080.a4a1fbe-0ubuntu2_amd64.deb - it’s not aewsome to hard code things like that, but it enables to build normally again for now.

If @xnox has any extra info on the dual-signed shim, and why including only the single-signed shim breaks install when using FDE, I would of course be very interested.

Cheers,
Just

1 Like