UC20: enabling Secure Boot + FDE on Raspberry PI4

[fguerzoni]

Hi
I wonder if UC20 Secure Boot and FDE features are fully supported on Raspberry PI4 bundled with OPTIGA TPM SLx 9670 TPM2.0 (SPI Interface)
I’m currently facing 2 main issues:

1. related to EFI system
2. related to spi and tpm modules not loaded in the kernel

EFI system
During UC20 boot the console displays:

secboot_tpm.go:80: checking if secure boot is enabled…
secboot_tpm.go:82: secure boot not enabled: not a supported EFI system
handlers_install.go:354: not encrypting device storage as checking TPM gave: not a supported EFI system

how is it possible to boot an EFI system?

Kernel modules
I noticed that the following modules:

• spi-bcm2835
• tpm_tis_spi
• tpm_tis_core
• tpm

are currently not loaded by default so, the device /dev/tpm0 is not available.
Manually loading those modules makes the device /dev/tpm0 available and addressable.

So I started building a custom UC20 image for raspberry with the idea to customize also the gadget snap to include the missing modules, but I ended suffering of the issue:

assertion is signed with expired public key

reported here:

Bug #1878422 “improve timesyncd epoch on uc20” : Bugs : ubuntu-core-initramfs

Custom UC20 Image for RPi4 fails

Hi unfortunately this is a known bug, the issue is that the time in the initrd is stuck at Nov 2019, so if you created the key that you signed your model assertion with after that date, then the image is unable to boot. You can check when your key was created with something like this (assuming that you replace NAME with the name of the key you used with snap sign -k, if you didn’t use -k, then the name is default): snap known account-key --remote public-key-sha3-384=$(snap keys | grep -Po '^NAM…

I’m quite lost, so if anyone could give an advice it would be really appreciated

[ogra]

the modules should be auto-loaded if dtoverlay=tpm-slb9670 is set in your config.txt … now, that said … these modules are most likely missing in the initrd so they could only be auto-loaded after mounting the rootfs … ignoring the initrd side for a moment, does the auto-loading work (on a non FDE system) if you add that dtoverlay option ?

[fguerzoni]

Sorry I forgot to mention,
I already placed:

dtparam=spi=on
dtoverlay=tpm-slb9670

in config.txt but no way: the modules were not auto loaded.

[ijohnson]

@fguerzoni

how is it possible to boot an EFI system?

Well I think it’s important to realize that with the default Raspberry Pi GPU firmware, the system is not EFI compatible, even if you add a TPM to it via the SPI interface. There are some experimental firmware choices out there that seek to enable the Pi to be fully EFI compatible, but they are not stable and don’t work with all the hardware on the Pi yet as I understand it, but even so you would have to re-architect the pi gadget to use them instead of the default Raspberry Pi upstream GPU firmware bits that we use in the gadget which come from the Raspberry Pi Foundation and are officially supported.

@fguerzoni

are currently not loaded by default so, the device /dev/tpm0 is not available.
Manually loading those modules makes the device /dev/tpm0 available and addressable.

You probably need to rebuild the kernel initrd with these modules set to load. In the initrd there is a file, /usr/lib/modules-load.d/ubuntu-core-initramfs.conf to which you can try adding those, then repack the initrd and rebuild your kernel snap, then rebuild your image and see if it works then.

@fguerzoni

So I started building a custom UC20 image for raspberry with the idea to customize also the gadget snap to include the missing modules, but I ended suffering of the issue:

assertion is signed with expired public key

This specific issue should actually be fixed in edge pi-kernel snaps I think, as long as you have created your signing keys in more than 2 weeks ago. If you created your keys sooner than that, then you will have to wait for the next snapd release, and then the next pi-kernel build to have code which moves time forward to the time your account-keys were created which will make the error go away.

If you are doing as I mention above and rebuilding the initrd, if you are using the edge kernel initrd as your base to modify from, you can simply touch the /usr/lib/epoch file to today’s timestamp and then it should unblock you with that custom kernel.

[fguerzoni]

Thank you @ijohnson. Lot of useful infos!
I’ll try to apply them and I’ll report the outcome.

In my specific use case I’m not very interested in GPU features. I want to use the device just to decode some HEVC video streams (which I don’t think it’s strictly related to GPU, let’s see…) and apply some detection/tracking logic on them. I don’t even plan to use OpenCL so I think the attempt deserve a try.

Regards

[ogra]

On a Pi the GPU driver is the bootloader since the boot process is first starting the GPU and only after this the ARM SoC gets initialized by the GPU.

So wether or not you are using any features of the GPU does not matter, you can not boot without using the proprietary driver/bootloader … (The original RPi chip was a leftover from a failed TV settop-box project, on such devices the GPU is the main processor and the ARM is only supplementary)

[fguerzoni]

Thank you @ogra,
I was not aware of that and at first I got quite surprised