UC20: enabling Secure Boot + FDE on Raspberry PI4

device
#1

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:


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

#2

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 ?

#3

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.

1 Like
#4

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.

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.

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.

1 Like
#5

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

#6

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)

#7

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

#8

Hi I am also having similar issue, did you manage to add tpm_tis_spi into pi-kernel snap and get it to work @fguerzoni ?

#9

No, I switched to other tasks but the TPM module is still on my desk waiting to be integrated

#10

I am gonna try and I will let you know if I get it to work. I download the pi-kernel snap and I added the tpm_tis_spi in modules.builtin file . But how do i compile it?

#11

Sorry, I cannot help you for that

#12

Hi, how do i build the kernel with my module added into initramfs.conf?

#13

Maybe @abeato or @stulluk could help you with that, I have done it before but it’s not well documented and I don’t have the time at the moment to recite all the steps, but basically the process is:

  • unpack the initramfs from an existing kernel snap
  • edit the conf file I linked to above to add what you want there
  • re-pack the initramfs
  • put the initramfs into the kernel snap
  • refresh/re-build the system with your kernel snap

I’m not sure if there’s a way to do the unpacking/repacking on amd64, I have always just unpacked it on a native arm64 system to make sure it works, something like this:

to unpack:

unsquashfs -d kernel-snap pi-kernel_*.snap 
unmkinitramfs initrd.img unpacked-initrd

to pack:

ubuntu-core-initramfs create-initrd --kernelver 5.4.0-1022-raspi --skeleton "$PWD/unpacked-initrd/" --kerneldir "$PWD/unpacked-initrd/main/lib/modules" --output "$PWD/repacked-initrd"

or something along those lines, that’s what I have in my bash history at least :grinning_face_with_smiling_eyes:

2 Likes
#14

note that there is also:

https://forum.snapcraft.io/t/build-pi-kernel-snap-with-tpm-tis-spi-module/26876/4

and @rahul-tt has filed an issue for the initrd at:

#15

Well I assume it would be useful for folks to be able to test it locally without waiting for the maintainers to test it out and include it

#16

definitely, i just wanted to point out that inclusion of the module in the initrd by default was requested …

#17

To run ubuntu-core-initramfs you would need to install the homonymous deb package from a PPA on an RPi, so maybe for packing the initrd back it might be easier to do:

cd unpacked-initrd
find . -print0 | cpio --null --create --quiet --format=newc --owner=0:0 | lz4 -9 -l > ../kernel-snap/initrd.img
cd ..
snap pack kernel-snap

(and this would work on amd64 too)

1 Like
#18

Hi i unpacked and modified the config file. But the ``` sudo ubuntu-core-initramfs create-initrd --kernelver 5.4.0-1044-raspi --skeleton “$PWD/unpacked-initrd/” --kerneldir “$PWD/unpacked-initrd/lib/modules” --output “$PWD/repacked-initrd”

cp: cannot stat '/home/ubuntu/kernel-snap/unpacked-initrd//main/.': No such file or directory "

Did you have this error before?
#19

for this i always get permission denied to access initrd.img even if i use sudo

#20

This works :slight_smile: , would this be sufficient for the initial disk encryption to work using TPM" module? @ogra