Thanks for your reply, @ijohnson. Is there a good way to get the logs out of the box? netconsole works only for kernel messages, or? Here a screenshot:
.The image is self-built but uses basically only the latest/stable components, e.g. snapd 2.51.4. Few days ago, I tried also the edge version of snapd without success.
Another try was to remove manually the fatal error from the snapd package by patching the secboot code, but this had only the effect that TPM got finally locked for some time.
With latest official edge 20210906.2 and stable, I get the same error, so independent from my custom build.
Hi, can you share some details about the hardware you are installing onto ?
I installed UC20 before on the hardware and it worked. I run into the same error when I installed another image on the same hardware. Do we need to clean up the keys in TPM?
It worked around the above issue but now I am at Creating custom image based on UC20
Please enter the recovery key for disk /dev/disk/by-label/ubuntu-data-enc: (press TAB for no echo)
What version of snapd are you creating this image with?
For any new install with FDE in Intel, you have to reset the TPM first. You will have to do that before any install attempt on the same device.
Cheers, Just
Are you using the standard pc gadget, or you’re own custom gadget ? Can we see your model assertion ?
Cheers, Just
Sorry, I cannot share the assertion here. I am using a custom gadget. The main difference with standard one is ‘prepare-device’ script.
Well, the gadget is likely where the issue is in this case.
Without knowing all the differences with the reference x86 gadget it will be hard to give you any advice I think. Using an efi executable signed with the incorrect keys can lead to that error, but I’m sure there are many other reasons. It’s probably a good idea to examine all the differences between the reference gadget and your own.
It appears, for some reason the key to unlock your data volume was not retrieved from the TPM. Perhaps there are more log lines before that error that can help.
This could provide some inspiration, where I had a similar error, but as I already said the reasons could be many, and could therefor be different: Changes in shim-signed packaging and breakages in UC20 secured grade model images on amd64
Cheers, Just
Thanks Just, will take a look into the logs. I upgraded BIOS to support Secure Boot and then enabled Secure Boot in BIOS. I also found there is an EFI partition in hardware. I saw grub64.efi and bootx64.efi. Are they used to boot UC20? I’m not sure how the EFI boot works since there are 2 places having *.efi files.
Regards,
sorry, missed the msg 
It is 2.52.1 on snapd stable channel.
I also tried this image, https://cdimage.ubuntu.com/ubuntu-core/20/stable/current/ubuntu-core-20-amd64+intel-iot.img.xz, and got the same error.
Update: sorry, FDE didn’t work before. I installed the image and then enabled Secure Boot in BIOS so it started successfully without FDE.
Update again: The error should be from this line, https://github.com/snapcore/secboot/blob/e3a397e2da905022392bf3b429d6892e9cc4f070/efi/secureboot_policy.go#L1034, but no idea how to work around it…
Hi @xanonid,
I am trying UC20 with fde on arm64 machine and I get
secboot_tpm.go:77: checking if secure boot is enabled…
secboot_tpm.go:79: secure boot not enabled: not a supported EFI system
taskrunner.go:271: [change 2 "Setup system for run mode" task] failed: cannot encrypt device storage as mandated by model grade secured: not a supported EFI system
May I ask how you enabled secure boot . I get a /dev/tpm0 port but during first boot TPM was not mentioned at all.
@rahul-tt note that if you are on arm64 and do not have UEFI, then you cannot take advantage of the automatic FDE, and instead need to implement full disk encryption hooks in your kernel snap. This is not yet fully documented, but you can take a look at examples in the snapd codebase: https://github.com/snapcore/snapd/blob/master/tests/nested/manual/uc20-fde-hooks/task.yaml and the hook itself: https://github.com/snapcore/snapd/blob/master/tests/lib/fde-setup-hook/fde-setup.go
Also please note do NOT use the code verbatim from those hooks - the “encryption” implemented there is just XOR’ing bytes to test that the hooks work, it is not a secure implementation.
Hi @ijohnson,
I did add fde-setup hook and added fde-revel-key into initrd/usr/bin. I have compiled the kernel and created an image. But I want to boot the image in Secure boot. I am following this documentation
But I am not able to quiet follow the procedure explained. Could you help me with this process.
I have created keys to sign the image. But when signing it requires PE/COFF image and I am not able to understand what that is.
$ signing-tool --sign --private-key=./private/archive-subkey-private.key --cert=./archive-subkey-public.crt --ca=./master-public.pkcs7 <PE/COFF image>
@rahul-tt where do you see the information from that page where it says to use signing-tool? I’m not familiar with that tool, when I need to resign EFI assets like grub, or kernel.efi to test secure boot with snakeoil keys for development I use this command:
sbattach --remove "$gadgetdir/shim.efi.signed"
SNAKE_OIL_DIR=/usr/lib/ubuntu-core-initramfs/snakeoil
sbsign --key "$SNAKE_OIL_DIR/PkKek-1-snakeoil.key" --cert "$SNAKE_OIL_DIR/PkKek-1-snakeoil.pem" --output "$gadgetdir/shim.efi.signed" "$gadgetdir/shim.efi.signed"
Hi @ijohnson,
I have a arm64 system. I downloaded pi-kernel snap and add fde-setup and fde-reveal-key to it. Would the process you mentioned to sign the kernel be valid on a arm64 pi-kernel snap too? Would sbsign work on that too?
The Raspberry Pi is not a UEFI system so no, you don’t need to sign any EFI assets there