Tdx-encrypted with partitions

Technical Support
, ,
21

Thank you, Jeremias. I will test it on the board on Monday.

Regarding the partition, I just changed the name from mmcblk2p2 to mmcblk2p3 for the tdx_enc_storage_location, then rebuilt it with the secure boot configuration, without any eFuse blown yet on the board.

In the previous post, I shared the ready-to-use config where the name is changed to mmcblk2p3. After that, I simply flashed the new image onto the board.

As for the Yocto build error, I will re-add the do_install step to the recipe.

By the way, thank you for your help, and have a great weekend! :slight_smile:

22

Regarding the partition, I just changed the name from mmcblk2p2 to mmcblk2p3 for the tdx_enc_storage_location, then rebuilt it with the secure boot configuration, without any eFuse blown yet on the board.

Okay so I did a build with the following configuration:

INHERIT += "tdx-signed"
TDX_IMX_HAB_CST_DIR = "/workdir/torizon/layers/cst"
INHERIT += "tdx-tezi-data-partition tdx-encrypted"
TDX_ENC_STORAGE_LOCATION = "/dev/mmcblk2p3"

I flashed the image to the device and the tdx-enc-handler fails with the following:

$ journalctl -n 100 -f -u tdx-enc-handler.service
Oct 09 15:18:14 localhost systemd[1]: Starting Encryption handler for Toradex modules...
Oct 09 15:18:14 localhost tdx-enc.sh[494]: caam: Preparing and checking system (generic)...
Oct 09 15:18:14 localhost tdx-enc.sh[508]: blockdev: cannot open /dev/mmcblk2p3: No such file or directory
Oct 09 15:18:14 localhost tdx-enc.sh[494]: caam: Blocks to be encrypted: 0...
Oct 09 15:18:14 localhost tdx-enc.sh[494]: caam: Reserved blocks: 0...
Oct 09 15:18:14 localhost tdx-enc.sh[494]: caam: Preparing and checking system (caam)...
Oct 09 15:18:15 localhost tdx-enc.sh[494]: caam: Setting up encryption key for CAAM backend...
Oct 09 15:18:15 localhost tdx-enc.sh[494]: caam: Configuring key in kernel keyring (type=trusted keyname=tdxenc)...
Oct 09 15:18:15 localhost tdx-enc.sh[494]: caam: Key blob not found. Creating it...
Oct 09 15:18:15 localhost tdx-enc.sh[494]: caam: Data preservation is not enabled
Oct 09 15:18:15 localhost tdx-enc.sh[494]: caam: Setting up partition with dm-crypt...
Oct 09 15:18:15 localhost tdx-enc.sh[519]: device-mapper: reload ioctl on encdata (251:0) failed: Invalid argument
Oct 09 15:18:15 localhost tdx-enc.sh[519]: Command failed.
Oct 09 15:18:15 localhost tdx-enc.sh[494]: caam: ERROR: Error setting up dm-crypt partition!
Oct 09 15:18:15 localhost systemd[1]: tdx-enc-handler.service: Main process exited, code=exited, status=1/FAILURE
Oct 09 15:18:15 localhost systemd[1]: tdx-enc-handler.service: Failed with result 'exit-code'.
Oct 09 15:18:15 localhost systemd[1]: Failed to start Encryption handler for Toradex modules.

I check the partitions on the device and see:

$ lsblk
NAME         MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
mmcblk2      179:0    0 14.8G  0 disk
|-mmcblk2p1  179:1    0  7.4G  0 part /var
|                                     /usr
|                                     /boot
|                                     /
|                                     /sysroot
`-mmcblk2p2  179:2    0  7.4G  0 part /var/rootdirs/media/DATA
mmcblk2boot0 179:32   0 31.5M  1 disk
mmcblk2boot1 179:64   0 31.5M  1 disk
zram0        253:0    0    0B  0 disk

So mmcblk2p3 truly does not exist which is why tdx-enc-handler fails. But this is the expected behavior in my perspective. When Linux enumerates things it usually goes in order. Since we’re making a new partition on the emmc (mmcblk2), and there is already a first partition for the main file system (mmcblk2p1). The expected behavior is that creating a new partition would be mmcblk2p2, it wouldn’t make sense for Linux to skip p2 and create a p3.

To double-check this I then did a second build where I had the secure-boot configuration disabled:

#INHERIT += "tdx-signed"
#TDX_IMX_HAB_CST_DIR = "/workdir/torizon/layers/cst"
INHERIT += "tdx-tezi-data-partition tdx-encrypted"
TDX_ENC_STORAGE_LOCATION = "/dev/mmcblk2p3"

I flashed this image and I saw the exact same behavior as with the image where the secure-boot was configuration enabled. The tdx-enc-handler service fails for the same reason and mmcblk2p3 still does not exist, which is what I would expect.

So unless I’m still not understanding what you did, I don’t see how you got this to “work” with the secure-boot configuration disabled.

In the previous post, I shared the ready-to-use config where the name is changed to mmcblk2p3. After that, I simply flashed the new image onto the board.

Maybe it’s a typo on your configurations, but in none of your previous configurations you’ve shared on this thread did you have TDX_ENC_STORAGE_LOCATION = "/dev/mmcblk2p3". All of your configurations I see on this thread you are specifying /dev/mmcblk2p2.

Please keep in mind TDX_ENC_STORAGE_LOCATION does not control what data partition gets created. This just controls what location the tdx-enc-handler will work with. It’s tdx-tezi-data-partition that is creating the data partition and it will create a partition on the emmc with the next enumeration which would be mmcblk2p2 in this case. There’s no option to tell the tdx-tezi-data-partition to skip mmcblk2p2 and create mmcblk2p3 instead.

Best Regards,
Jeremias

23

Hi @Srimoki,
I have just got back onto updating my encryption stuff on my project.
Will try to dig out what I did for adding the extra file into the image.
If I remember correctly it is a bbappend that adds an extra python function to the TAR processing.
I actually had 2 parts.
The first to strip a directory out of the rootfs and the second to include the new archive in the image so it matches the image.json.

Currently I’m adding my custom OTPMK changes to latest committed code to protect us from screwing our encrypted partition when blowing the SEC_BOOT fuse.

Regards,

24

@Srimoki,

izzycoding here from my work account…
Attached here is a rough example of what I generally do for the image building (this may not work verbatum as I have just pulled out the basics from my work codebase as lots of it cannot be shared for legal reasons).

image_type_tezi_data.bbclass (954 Bytes)

Basically it updates and defines a few variables (based on using the new tezi data partition class). Then it creates a new image type which pulls the /data folder out of the rootfs into the new image. Then it updates the rootfs image to exclude the /data folder.

Hope that helps.

25

@Srimoki,

I have just been given the task to “clean-up” my custom layers now and have added some patches that may be useful for you to one of my other questions on here is-there-an-easy-way-to-create-a-dual-rootfs-tezi-image.

The first patch adds the dual rootfs partitions and the second one applies the data partition extraction.
I apply these to the relevant layers using git am -3 --ignore-whitespace --ignore-space-change --signoff < {patch-file-path} after I have done a repo sync.

With these in place, I can then just put anything I need as normal into the rootfs under the required data mountpoint (see: TDX_TEZI_DATA_PARTITION_MOUNTPOINT). Make sure you also set TDX_ENC_STORAGE_MOUNTPOINT to the same path if encrypting it.

I am currently running tests on my builds to make sure it works as expected. Hopefully something like this will be added to the Toradex BSP and Security layers soon.

Regards,