Fresh setup with standard image fails

[LimaLima]

v1.1.0 Configuration:

CUSTOMER_KEY_FILE_PEM=/deploy/private.pem
CUSTOMER_KEY_PKCS11_NAME=
GOLD_MASTER_OS_FILE=/deploy/2024-07-04-raspios-bookworm-arm64-lite.img
RPI_DEVICE_STORAGE_TYPE=emmc
RPI_DEVICE_FAMILY=4
RPI_DEVICE_BOOTLOADER_CONFIG_FILE=/var/lib/rpi-sb-provisioner/bootloader.config
RPI_DEVICE_LOCK_JTAG=
RPI_DEVICE_EEPROM_WP_SET=
RPI_DEVICE_SERIAL_STORE=/usr/local/etc/rpi-sb-provisioner/seen
DEMO_MODE_ONLY=
RPI_SB_WORKDIR=/srv/provision-work

Running on a fresh install of Pi4, based on the same 2024-07-04-raspios-bookworm-arm64-lite.img Targeting CM4 (8GiB MMC, 1 GiB RAM, no wifi) on IO Board, as per documentation

After "successful" provisioning, boot fails before switching to encrypted partition: boot.img/initramfs8 does not contain uncompressed kernel modules that are required here, but it has their .xz versions

[LimaLima]

p.s. rpi-otp-private-key returns zeros on the target CM4. I was expecting it to have something random after provisioning.

[tdewey-rpi]

Thanks for the report, @LimaLima

I'm hoping to reproduce this on CM4 either later today or tomorrow.

Your observations are essentially correct - I'd have expected to see a device-unique key returned, and that you just have zeros implies that the keywriter failed on your device.

[LimaLima]

Ok, so we have two problems then:

1. key provisioning not generating a disk encryption key
2. compressed kernel modules being copied to a kernel that expects uncompressed ones

Any suggested workarounds, or some additional information I could collect?

[LimaLima]

Some further testing:

1. Cleared RPI_SB_WORKDIR folder (workaround for the issue #42)
2. Took a cm4 module with a random numbers already burned into OTP using rpi-otp-private-key (workaround for key provisioning issue)
3. Modified the image using unxz -k required.ko.xz to make sure the modules are available (workaround for cryptoroot incompatibility with compressed modules)

Provisioning went through "successfully" However, LUKS is locked:

Confirmed manually: Even tried with a key made out of 0'os:

Need to find additional workarounds :(

[tdewey-rpi]

Thanks for the report, @LimaLima

Unfortunately, when dealing with secure boot, workarounds are seldom what you actually want. In this case, it looks like we've had a range of reports that the Fastboot gadget OS in 1.1.0 is faulty - resulting in a failure to write keys to OTP.

This is particularly unfortunate - because that key is a hard dependency for the later stages. In particular, the key written to OTP would have been used as the device-unique key for encrypting the rootfs.

Deleting the SB_WORKDIR as you did would have advanced the stages - but you were already in a bad state at that time, so progressing wouldn't have been useful.

I can see a few actions from this report that need to happen:

1) Fix the fastboot gadget 2) Harden the provisioner step to only begin when keywriting has reported success.

[LimaLima]

Clearing SB_WORKDIR is required as a workaround for the "fastpath" making a jump at provisioner.sh#L258 which skips this line: DISK_IDENTIFIER="$(sfdisk --disk-id "${LOOP_DEV}")" which is then expected to be available in provisioner.sh#L431

Given the current state of the provisioner, can you recommend how to verrify the successful execution of revoke_devkey and program_jtag_lock?

[tdewey-rpi]

Given the current state of the provisioner, can you recommend how to verify the successful execution of revoke_devkey and program_jtag_lock?

The only non-destructive way is to observe the device metadata, which can be done by setting a flag in the rpi-sb-provisioner configuration, or manually by following the steps in the config.txt comment when using rpiboot: https://github.com/raspberrypi/usbboot/blob/d0a2ed95ade02fbc042d325a22e4a7abcaf8fd34/secure-boot-recovery/config.txt#L45

[tdewey-rpi]

I've just cut v1.1.1, which I've used to provision a Raspberry Pi OS 64-bit desktop image onto a Compute Module - including automatic unlock via the Device Unique Key.

Please give that one a try, as I believe this release resolves this problem. Holding open for 2 weeks to verify.

[tdewey-rpi]

Closing as stale - I've not reason to believe this fails on >1.1.1, and I've had no response.