Tdx-encrypted with partitions

I’m using the Verdin iMX8M Plus SOM and Torizon version 7.0.

I’m trying to encrypt the partition following the documentation from git. My local.conf looks like this:

INHERIT += "tdx-tezi-data-partition"
INHERIT += "tdx-encrypted"
TDX_ENC_STORAGE_LOCATION = "/dev/mmcblk2p2"
TDX_TEZI_DATA_PARTITION_AUTOMOUNT = "0"


TDX_ENC_KEY_BACKEND = "caam"
TDX_ENC_KEY_LOCATION = "filesystem"
TDX_ENC_KEY_DIR = "/var/local/private/.keys"
TDX_ENC_KEY_FILE = "tdx-enc-key.blob"

I was able to build the image and flash it to the device. However, it didn’t create any partition on the device. Here is the output of lsblk:

torizon@verdin-imx8mp-15207741:~$ lsblk
NAME         MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
mmcblk2      179:0    0 29.1G  0 disk 
`-mmcblk2p1  179:1    0 29.1G  0 part /var
                                      /usr
                                      /boot
                                      /
                                      /sysroot
mmcblk2boot0 179:32   0    4M  1 disk 
mmcblk2boot1 179:64   0    4M  1 disk 
zram0        253:0    0    0B  0 disk 
torizon@verdin-imx8mp-15207741:~$ ls /var/local/private/
torizon@verdin-imx8mp-15207741:~$ 

How is the tdx-tezi-data-partition supposed to work, and how can I configure it to create another partition on the eMMC and then encrypt it?

What I’m trying to do is test the encryption to gain a better understanding of it. Will it work if I create the key like this:

TDX_ENC_KEY_BACKEND = "caam"
TDX_ENC_KEY_LOCATION = "filesystem"
TDX_ENC_KEY_DIR = "/var/local/private/.keys"
TDX_ENC_KEY_FILE = "tdx-enc-key.blob"

and then set automount to 0 with this:

TDX_TEZI_DATA_PARTITION_AUTOMOUNT = "0"

and use the .blob key file to unlock the partition at runtime?

Thank you for your help!

Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!

Did you like my answer?

:+1: :-1:


Hello,

Thank you for reaching out with your question about encrypting partitions on the Verdin iMX8M Plus SOM using Torizon 7.0. Let’s go through the steps to ensure your configuration is set up correctly.

  1. Understanding tdx-tezi-data-partition: This feature is designed to create a data partition on your device, which can then be encrypted. If configured correctly, the partition should be created during the build process.

  2. Configuration Check:

    • Ensure your local.conf file includes the necessary inheritance and variables:
      INHERIT += "tdx-tezi-data-partition"
      INHERIT += "tdx-encrypted"
      TDX_ENC_STORAGE_LOCATION = "/dev/mmcblk2p2"
      TDX_TEZI_DATA_PARTITION_AUTOMOUNT = "0"
      TDX_ENC_KEY_BACKEND = "caam"
      TDX_ENC_KEY_LOCATION = "filesystem"
      TDX_ENC_KEY_DIR = "/var/local/private/.keys"
      TDX_ENC_KEY_FILE = "tdx-enc-key.blob"
      
    • Verify that TDX_ENC_STORAGE_LOCATION points to the correct partition you intend to encrypt.
  3. Build Process:

    • Make sure you are using the meta-toradex-security layer and that your build environment is set up correctly with Yocto Project/OpenEmbedded.
    • Rebuild the image after making any changes to the configuration to ensure they are applied.
  4. Partition Creation:

    • If the partition is not being created, check the build logs for any errors or warnings related to partition creation.
    • Ensure that the device has enough space and that the partition table allows for additional partitions.
  5. Using the .blob Key File:

    • The configuration you provided for the key file should work if the key is correctly generated and stored at the specified location.
    • Ensure that the key file is accessible at runtime and that the CAAM backend is properly configured to use it.

By following these steps, you should be able to create and encrypt a partition on your device. If issues persist, double-check each configuration step and ensure that all dependencies and tools are correctly installed and configured.

I hope this helps you with your encryption setup. If you have any more questions, feel free to ask.

Best regards,
Toradex AI Assistant

Please, also check if these links can help you solve your problem:

Tdx-encrypted with tdx-tezi-data-partition.

Greetings @Srimoki,

Could you please provide some additional details regarding your setup here.

  • First of all in your Yocto build for this, what is the git hash/commit you are using for meta-toradex-security?
  • On your device where you flashed this image did you notice any relevant logs during boot or in dmesg related to this issue?
  • Could you run journalctl -f -u tdx-enc-handler.service on your device and share the logs so we can review the logs from the service doing the encryption.

How is the tdx-tezi-data-partition supposed to work, and how can I configure it to create another partition on the eMMC and then encrypt it?

The way it should work is that this will create an additional partition on the emmc during the image flashing from Easy Installer. Though in your case for some reason it seems this additional partition did not get created for some reason.

Furthermore if you have tdx-encrypted enabled in addition to tdx-tezi-data-partition, then the created additional partition should also be encrypted by the functionality described here: meta-toradex-security/docs/README-encryption.md at scarthgap-7.x.y · toradex/meta-toradex-security · GitHub

Anyways, please provide the additional information I requested and let’s see if we can first figure out why the additional data partition isn’t being created in the first place.

Best Regards,
Jeremias

Hi Jeremias

Thank you for your respons. Below are the details you requested:

Git Commit
I am using the following commit for meta-toradex-security: HEAD:e2da655

Device Logs
Here is the full dmesg log from the device:
dmesg.log (50.4 KB)

Journalctl Output
Below is the output of the journalctl -f -u tdx-enc-handler.service command:

torizon@verdin-imx8mp-15207741:~$ journalctl -f -u tdx-enc-handler.service
Jan 13 09:20:33 verdin-imx8mp-15207741 tdx-enc.sh[504]: caam: Encrypted key exists. Importing it...
Jan 13 09:20:33 verdin-imx8mp-15207741 tdx-enc.sh[520]: 284224567
Jan 13 09:20:33 verdin-imx8mp-15207741 tdx-enc.sh[504]: caam: Data preservation is not enabled
Jan 13 09:20:33 verdin-imx8mp-15207741 tdx-enc.sh[504]: caam: Setting up partition with dm-crypt...
Jan 13 09:20:33 verdin-imx8mp-15207741 tdx-enc.sh[523]: device-mapper: reload ioctl on encdata (252:0) failed: Invalid argument
Jan 13 09:20:33 verdin-imx8mp-15207741 tdx-enc.sh[523]: Command failed.
Jan 13 09:20:33 verdin-imx8mp-15207741 tdx-enc.sh[504]: caam: ERROR: Error setting up dm-crypt partition!
Jan 13 09:20:33 verdin-imx8mp-15207741 systemd[1]: tdx-enc-handler.service: Main process exited, code=exited, status=1/FAILURE
Jan 13 09:20:33 verdin-imx8mp-15207741 systemd[1]: tdx-enc-handler.service: Failed with result 'exit-code'.
Jan 13 09:20:33 verdin-imx8mp-15207741 systemd[1]: Failed to start Encryption handler for Toradex modules.

Let me know if you need me to clarify anything or provide more data to help debug this issue.

Based on the information you provided I did some testing on my side. I created my own image with the following in local.conf:

INHERIT += "tdx-tezi-data-partition tdx-encrypted"
TDX_ENC_STORAGE_LOCATION = "/dev/mmcblk2p2"

Everything else was set to the default value as per the README docs. The resulting image seems to work fine for me when flashed:

torizon@verdin-imx8mp-06849059:~$ lsblk
NAME         MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
sda            8:0    1 29.1G  0 disk
`-sda1         8:1    1 29.1G  0 part /var/rootdirs/media/COSTCO_USB
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
  `-encdata  252:0    0  7.4G  0 dm   /run/encdata
mmcblk2boot0 179:32   0 31.5M  1 disk
mmcblk2boot1 179:64   0 31.5M  1 disk
zram0        253:0    0    0B  0 disk
torizon@verdin-imx8mp-06849059:~$ journalctl -f -n 100 -u tdx-enc-handler
Oct 09 15:18:14 localhost systemd[1]: Starting Encryption handler for Toradex modules...
Oct 09 15:18:14 localhost tdx-enc.sh[457]: caam: Preparing and checking system (generic)...
Oct 09 15:18:14 localhost tdx-enc.sh[457]: caam: Blocks to be encrypted: 15540224...
Oct 09 15:18:14 localhost tdx-enc.sh[457]: caam: Reserved blocks: 0...
Oct 09 15:18:14 localhost tdx-enc.sh[457]: caam: Preparing and checking system (caam)...
Oct 09 15:18:14 localhost tdx-enc.sh[457]: caam: Setting up encryption key for CAAM backend...
Oct 09 15:18:14 localhost tdx-enc.sh[457]: caam: Configuring key in kernel keyring (type=trusted keyname=tdxenc)...
Oct 09 15:18:14 localhost tdx-enc.sh[457]: caam: Key blob not found. Creating it...
Oct 09 15:18:14 localhost tdx-enc.sh[457]: caam: Data preservation is not enabled
Oct 09 15:18:14 localhost tdx-enc.sh[457]: caam: Setting up partition with dm-crypt...
Oct 09 15:18:14 localhost tdx-enc.sh[480]: Name:              encdata
Oct 09 15:18:14 localhost tdx-enc.sh[480]: State:             ACTIVE
Oct 09 15:18:14 localhost tdx-enc.sh[480]: Read Ahead:        256
Oct 09 15:18:14 localhost tdx-enc.sh[480]: Tables present:    LIVE
Oct 09 15:18:14 localhost tdx-enc.sh[480]: Open count:        0
Oct 09 15:18:14 localhost tdx-enc.sh[480]: Event number:      0
Oct 09 15:18:14 localhost tdx-enc.sh[480]: Major, minor:      252, 0
Oct 09 15:18:14 localhost tdx-enc.sh[480]: Number of targets: 1
Oct 09 15:18:14 localhost tdx-enc.sh[457]: caam: Mounting encrypted partition...
Oct 09 15:18:14 localhost tdx-enc.sh[457]: caam: Formatting encrypted partition with ext4...
Oct 09 15:18:17 localhost tdx-enc.sh[457]: caam: Data preservation is not enabled
Oct 09 15:18:17 localhost tdx-enc.sh[457]: caam: Success!
Oct 09 15:18:17 localhost systemd[1]: Finished Encryption handler for Toradex modules.

I even tried a second image with the following in my local.conf as well:

TDX_TEZI_DATA_PARTITION_AUTOMOUNT = "0"

Still the same result. Are you sure the image that you are flashing to the device has the extra data partition enabled? It seems like it does not based on your logs and information.

The folder you used to flash the image with Toradex Easy Installer, inside that folder there should be a file called image.json. Could you please share the contents of this file.

Best Regards,
Jeremias

Hi Jeremias.tx

I was able to successfully create and encrypt a partition. The issue turned out to be related to the method we used to flash the new image. Initially, we flashed the image via SSH, but it seems this process did not update certain components related to encryption properly. Once we set the devkit to recovery mode and used the Toradex Easy Installer to update it, everything worked as expected.

I’m wondering, what are the differences between updating via SSH and using the Toradex Easy Installer? Specifically, why might encryption-related components not update correctly with the SSH method?

Additionally, I noticed something unusual while building the image with TDX_TEZI_DATA_PARTITION_AUTOMOUNT = "0". From the logs_0.md (45.0 KB), it seems that the disk is still automounted and then unlocked, behaving as if automount were enabled. I also tried setting TDX_TEZI_DATA_PARTITION_AUTOMOUNT = "-1" logs_-1.md (44.9 KB), but the result was the same.

What I’m trying to achieve is to boot the device with the partition encrypted and have the ability to manually unlock it during runtime using a “key” whenever we need to write data to the partition. Once the operation is done, I’d like to lock it again. Is this possible to do it?

Also, what should I expect when the partition is “encrypted”? For example, should I see the device as active but unable to read or write any data to the encrypted partition without unlocking it?

Thank you for your insights!

I’m wondering, what are the differences between updating via SSH and using the Toradex Easy Installer? Specifically, why might encryption-related components not update correctly with the SSH method?

First of all what do you mean by you used SSH to “flash” the image? The only method we officially support for flashing the eMMC on our devices is with Toradex Easy Installer.

As for why it didn’t work with your other method. As I alluded to previously it’s Toradex Easy Installer that creates the data partition enabled by tdx-tezi-data-partition. This is done during the flashing process. That is why in your case you didn’t have /dev/mmcblk2p2 since Easy Installer wasn’t there to create it on your side.

What I’m trying to achieve is to boot the device with the partition encrypted and have the ability to manually unlock it during runtime using a “key” whenever we need to write data to the partition. Once the operation is done, I’d like to lock it again. Is this possible to do it?

The way our data-at-rest encryption feature works is that it takes the mentioned filesystem location and encrypts it using the Trusted and Encrypted Keys framework present in Linux: Trusted and Encrypted Keys — The Linux Kernel documentation

As you noticed this newly encrypted location is then mounted and opened for standard use. This entire behavior is automated and controlled by this script that runs on boot via systemd service: meta-toradex-security/recipes-core/tdx-enc-handler/tdx-enc-handler/tdx-enc.sh at kirkstone-6.x.y · toradex/meta-toradex-security · GitHub

If you want different behavior you would need to modify this script or provide your own for the desired behavior. Keep in mind our meta-toradex-security layer provides a baseline general security. Of course there’s no such thing as a security solution that fits every use-case so it’s not unexpected for users like yourself to tweak and modify what we provide to fit your own requirements.

Also, what should I expect when the partition is “encrypted”? For example, should I see the device as active but unable to read or write any data to the encrypted partition without unlocking it?

Well if location on the filesystem is encrypted then you won’t really be able to access it and it’s contents until it has been mounted and decrypted with the appropriate credentials. The rest o the filesystem should behave as normal though. Again I would refer you to our script as an example of how we do it. Keep in mind our data-at-rest encryption feature is just encrypting a single location/partition on the filesystem, it’s not encrypting the "entire “device”.

Do you need the entire device to be encrypted?

Best Regards,
Jeremias

Hi @Srimoki ,

As @jeremias.tx has mentioned, it will be the enc-handler service doing this.
If I remember correctly, there is a way to disable this service in systemd so that it won’t auto-start.

Previously, I have created my own wrapper around this that starts and stops it on first boot (in my case after the SEC_BOOT fuse is blown) to ensure the partition is initially encrypted. Then it immediately stops the service, which will lock it again.

For manual access you could either run the existing service, or replicate it after moving the key blob to where you need it.

Regards,
Izzy

As far as I’m aware, the TDX_TEZI_DATA_PARTITION_AUTOMOUNT option refers to an entry in /etc/fstab that looks for a volume with LABEL=DATA and mounts it without encryption (I didn’t know about this option and used sed in a base-files_%bbappend to remove the fstab entry). Mounting of the partition when it’s encrypted, however, is taken care of by the encryption handler service, which also has a stop function for unmounting. If you want to access the encrypted volume only at certain times, I might suggest uninstalling the service from local-fs.target.wants so you can start and stop it as needed.

About the SSH flash, I used the Toradex builder SSH to deploy the image like this:

$ torizoncore-builder deploy --remote-host 192.168.1.117 --remote-username torizon --remote-password torizon --reboot

And yes, our goal is to have the entire device encrypted so that if someone tries to remove the eMMC disk and read the data, they won’t be able to. If we can’t encrypt the entire device, we might consider another solution: storing all of our data in a separate partition and retrieving it only when needed.

I’ll explore the enc-handler service to see how it works.

And yes, our goal is to have the entire device encrypted so that if someone tries to remove the eMMC disk and read the data, they won’t be able to. If we can’t encrypt the entire device, we might consider another solution: storing all of our data in a separate partition and retrieving it only when needed.

Just to understand your goal better, do you really need the entire device encrypted? Or is it just certain information that needs to be protected? If it’s just select information, then probably just putting that into a separate encrypted partition would suffice just as you said. It would probably be easier to work with and implement than encrypting the entire device/root filesystem as well.

Best Regards,
Jeremias

1 Like

@Srimoki

I have previously tried to do similar but based on the reference minimal image (not torizon OS).
It would be much easier for you to encrypt a partition with your data in.
As long as you keep it in a similar format, you could later mount it as a layer in an overlayFS.

This is currently what I am doing for proof-of-concept device.

Regards,
Izzy

1 Like

Thanks for the advice so far! My ultimate goal is to have the entire device encrypted, but it seems like that’s going to take more time and research to figure out properly. If you have any tips or recommendations on how to achieve this, I’d love to hear them.

For now, i just need a separate encrypted partition where we can store our data. I’ve been experimenting with the tdx-enc-handler and ran into a question:

Issue with Secure Boot and Partition Creation:

I’m trying to create a new partition with Secure Boot enabled (eFuses haven’t been blown yet). However, when Secure Boot is enabled, the system can’t create the new partition during the image build. Once I disable Secure Boot, the partition can be created without any issues.

So my question is: Is it possible to create a new partition while Secure Boot is enabled?

Here’s my current Secure Boot configuration:

INHERIT += "tdx-tezi-data-partition"
INHERIT += "tdx-encrypted"

TDX_ENC_STORAGE_LOCATION = "/dev/mmcblk2p2"
# TDX_TEZI_DATA_PARTITION_LABEL = "verge-encrypted"
TDX_TEZI_DATA_PARTITION_AUTOMOUNT = "0"


TDX_ENC_KEY_LOCATION = "filesystem"
TDX_ENC_KEY_DIR = "/var/local/private_1/.keys"
TDX_ENC_KEY_FILE = "tdx-enc-key.blob"

TDX_ENC_STORAGE_MOUNTPOINT = "/secure"

# Secure Boot
INHERIT += "tdx-signed"
# Directory containing the Code Signing Tool 
TDX_IMX_HAB_CST_DIR = "/app/oe-core/layers/cst-3.4.1_verdin"
# Cryptographic algorithm 
TDX_IMX_HAB_CST_CRYPTO = "rsa"
TDX_IMX_HAB_ENABLE = "1"
UBOOT_SIGN_ENABLE = "1"
# Enable SRK CA flag (set to "1" for HAB/AHAB)  
TDX_IMX_HAB_CST_SRK_CA = "1"
# Key length for RSA keys
TDX_IMX_HAB_CST_KEY_SIZE = "2048"
# Digest algorithm for signing (SHA-256)
TDX_IMX_HAB_CST_DIG_ALGO = "sha256"

Here’s the error log from tdx-enc-handler.service for reference:

x tdx-enc-handler.service - Encryption handler for Toradex modules
     Loaded: loaded (/usr/lib/systemd/system/tdx-enc-handler.service; enabled; preset: enabled)
     Active: failed (Result: exit-code) since Wed 2024-10-09 15:18:14 UTC; 3 months 14 days ago
   Main PID: 462 (code=exited, status=1/FAILURE)
        CPU: 112ms

Oct 09 15:18:14 localhost tdx-enc.sh[462]: caam: Configuring key in kernel keyring (type=trusted keyname=tdxenc)...
Oct 09 15:18:14 localhost tdx-enc.sh[462]: caam: Key blob not found. Creating it...
Oct 09 15:18:14 localhost tdx-enc.sh[462]: caam: Data preservation is not enabled
Oct 09 15:18:14 localhost tdx-enc.sh[462]: caam: Setting up partition with dm-crypt...
Oct 09 15:18:14 localhost tdx-enc.sh[488]: device-mapper: reload ioctl on encdata (252:0) failed: Device or resource busy
Oct 09 15:18:14 localhost tdx-enc.sh[488]: Command failed.
Oct 09 15:18:14 localhost tdx-enc.sh[462]: caam: ERROR: Error setting up dm-crypt partition!
Oct 09 15:18:14 localhost systemd[1]: tdx-enc-handler.service: Main process exited, code=exited, status=1/FAILURE
Oct 09 15:18:14 localhost systemd[1]: tdx-enc-handler.service: Failed with result 'exit-code'.

Question about Yocto Build
Is there a way to include specific files in the encrypted partition during the Yocto build process?

For example:
Let’s say I have a file called aws.sh. When the system boots for the first time and creates the encrypted partition, I want this file to already be in the partition automatically.

So far, I’ve tried something like this:

install -d ${D}${TDX_ENC_STORAGE_MOUNTPOINT}/.file/scripts
install -m 0644 ${WORKDIR}/aws.sh${D}${TDX_ENC_STORAGE_MOUNTPOINT}/.file/scripts/aws.sh

I’ve tested this, and it looks like the file is now being placed in the /secure path as the partition is mounted, or is there a better way to handle this?

Thanks in advance for your help! I really appreciate it.

@Srimoki

Do you mean you’re having issues with the encrypted partition after blowing the fuse?

I had this issue because the key created before blowing the fuse is a test one.
Initially, the tdx-enc-handler encrypts the partition and stores the blob file (this is kind of an identifier for the key in the caam).
If you then reboot to blow the secure boot fuse, it will fail to find the key (because it is not using the test one anymore).
It will continue the usual process, but it will fail to initially mount the partition as it’s already encrypted.
That is the ioctl error in the log.
After that the process just stops with a failed state.

You will need to either reverse the encryption before blowing the fuse so that the partition is re-encrypted on first boot afterwards.
Or, you could disable the tdx-enc-handler service initially, and then re-enable it after blowing the fuse (this depends on if you have a read-only rootfs though).
If you do, I would also suggest moving the key blob to be “in the partition” too, otherwise this will not persist between reboots.

Alternatively, I am working on a patch I soon hope to create a PR for that will provide another variable to delay the encryption until after the fuse is blown.

Regards,
Izzy

@Srimoki

In relation to having data in the partition, you will need to manually extract the secure directory such that yocto makes it a different archive in the image and manifest.
Possibly not to difficult if you’re already modifying that. It’s just defining a new Image type that the rootfs depends on (so it is removed before building the rootfs).

If you can get the data into the partition initially, then there is a variable in the tdx-enc-handler that will ensure the data persists when encrypting it (that was my previous PR for the enc-handler stuff).
Basically it copies the content into ram then back after the encryption is done.
You can see in the log you posted that is currently not being done.

I would certainly test all of this before blowing the secure boot fuse. In my experience it takes a fair few attempts to get it right :grin:.

Regards,
Izzy

Thank you so much, izzycoding ! Your reply really cleared things up and was super helpful. The points you brought up are excellent and I hadn’t even thought about some of them when setting up the partition.

Regarding the partition issue, I ran into a problem when no efuse had been blown yet, but all the other secure boot steps were already in place.

During my tests, I tried creating a new partition called mmcblk2p3, but it failed (as shown in the earlier logs) unless I removed the secure boot config from local.conf. Once I did that, everything worked as expected, and I was able to modify mmcblk2p2 or create a new mmcblk2p3 without any issues.

Also, big thanks for the Yocto build tips! I’m still learning how to use it, so your advice is invaluable. I’ll be running some tests tomorrow. For now, I was planning to blow a fuse today, but since I only have one board with me, I need to make sure everything is 100% working first so can’t afford any mistakes :joy::joy:

Hi @Srimoki,

During my tests, I tried creating a new partition called mmcblk2p3, but it failed (as shown in the earlier logs) unless I removed the secure boot config from local.conf. Once I did that, everything worked as expected, and I was able to modify mmcblk2p2 or create a new mmcblk2p3 without any issues.

Just to clarify are you creating this mmcblk2p3 partition manually? In your most recent configuration you shared I didn’t see any mention of a mmcblk2p3. Could you describe in more detail how exactly how you are creating this new partition?

On my side if I create a partition via tdx-tezi-data-partition then everything works as expected. For reference I have the following config:

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

The resulting image has the expected mmcblk2p2 partition and the tdx-enc-handler was succesful:

torizon@verdin-imx8mp-06849059:~$ lsblk
NAME         MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
sda            8:0    1 29.1G  0 disk
`-sda1         8:1    1 29.1G  0 part /var/rootdirs/media/COSTCO_USB
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
  `-encdata  251:0    0  7.4G  0 dm   /run/encdata
mmcblk2boot0 179:32   0 31.5M  1 disk
mmcblk2boot1 179:64   0 31.5M  1 disk
zram0        253:0    0    0B  0 disk
torizon@verdin-imx8mp-06849059:~$ journalctl -f -u tdx-enc-handler.service
Jan 24 00:26:30 verdin-imx8mp-06849059 tdx-enc.sh[472]: Tables present:    LIVE
Jan 24 00:26:30 verdin-imx8mp-06849059 tdx-enc.sh[472]: Open count:        0
Jan 24 00:26:30 verdin-imx8mp-06849059 tdx-enc.sh[472]: Event number:      0
Jan 24 00:26:30 verdin-imx8mp-06849059 tdx-enc.sh[472]: Major, minor:      251, 0
Jan 24 00:26:30 verdin-imx8mp-06849059 tdx-enc.sh[472]: Number of targets: 1
Jan 24 00:26:30 verdin-imx8mp-06849059 tdx-enc.sh[453]: caam: Mounting encrypted partition...
Jan 24 00:26:30 verdin-imx8mp-06849059 tdx-enc.sh[490]: /dev/mapper/encdata: UUID="2c4f97ea-3ecc-4be5-a6e6-5589f4c8f6a4" BLOCK_SIZE="4096" TYPE="ext4"
Jan 24 00:26:31 verdin-imx8mp-06849059 tdx-enc.sh[453]: caam: Data preservation is not enabled
Jan 24 00:26:31 verdin-imx8mp-06849059 tdx-enc.sh[453]: caam: Success!
Jan 24 00:26:31 verdin-imx8mp-06849059 systemd[1]: Finished Encryption handler for Toradex modules.

I’ll need more info about how you’re creating this mmcblk2p3 partition so I can try to recreate/investigate further.

Is there a way to include specific files in the encrypted partition during the Yocto build process?

There might be a path here you can try with Toradex Easy Installer. As you know our Easy Installer tool is our main method of flashing software to our modules. If you look in the folder that is used for installation you should see an image.json file. This is the configuration file that tells Easy Installer how to flash the eMMC of the module. Here’s a snippet of the file:

"blockdevs": [
        {
            "name": "emmc",
            "partitions": [
                {
                    "partition_size_nominal": "512",
                    "want_maximised": true,
                    "content": {
                        "label": "otaroot",
                        "filesystem_type": "ext4",
                        "mkfs_options": "-E nodiscard",
                        "filename": "torizon-docker-verdin-imx8mp.ota.tar.zst",
                        "uncompressed_size": 669.9140625
                    }
                },
                {
                    "partition_size_nominal": "512",
                    "partition_type": "83",
                    "want_maximised": true,
                    "content": {
                        "label": "DATA",
                        "filesystem_type": "ext4",
                        "mkfs_options": "-E nodiscard",
                        "filename": ""
                    }
                }
            ]
        },

You can see here this is creating 2 partitions in eMMC one is for the main rootfs and the other is the data partition. The initial contents of each partition is dictated by the filename field. You can see the first partition will contain the contents of torizon-docker-verdin-imx8mp.ota.tar.zst, which contains the main root filesystem of the image. The 2nd partition has nothing for filename which is why there’s nothing in it at the start.

So if you populate this and provide a respective file/tar archive then the contents of that will be flashed to the extra data partition. In yocto you can populate this field via the TEZI_DATA_FILES variable: image_type_tezi.bbclass « classes - meta-toradex-bsp-common.git - Toradex BSP layer, recipes common to all modules

However, you still need a recipe of some kind to create the files/archive that you will be set to this variable. Then as @izzycoding suggested you’ll need to set TDX_ENC_PRESERVE_DATA to prevent your initial data from being deleted upon setup of the encrypted partition.

Best Regards,
Jeremias

Hello jerematias,

I created the mmcblk2p3 partition through the local.conf, not manually :grimacing:.

Here’s what I’ve done so far:

First, I created the mmcblk2p2 partition without enabling secure boot on the device. Everything worked exactly as expected.

Then, I enabled the secure boot settings and flashed a new image onto the device using Tezi (still without blowing the efuse).

After that, I tried changing the partition name from mmcblk2p2 to mmcblk2p3 and flashed the image again (with secure boot enabled but still without blowing the efuse). That’s when I got the error I mentioned in my previous post.

However, when I disabled the secure boot settings and flashed the image again with the name change for the partition, everything worked fine again.

Hello izzicoding,

Could you provide more details on how you achieved this?

My image.json contains the following entry for the secure data partition:

"secure_data_01": {
    "partition_size_nominal": "512",
    "partition_type": "83",
    "want_maximised": true,
    "content": {
        "label": "DATA",
        "filesystem_type": "ext4",
        "mkfs_options": "-E nodiscard",
        "filename": "secure_data_01"
    }
}

This configuration is generated automatically during the build. However, the final image file (torizon-docker-verdin-imx8mp-Tezi.tar) doesn’t include the secure_data_01 partition at all.

While trying to resolve this with my .bb, I ran into the following issue during the build process:


Problem: d-tools zram locale-base-en-us returned 1:
DNF version: 4.19.0
cachedir: /app/oe-core/build/tmp/work/verdin_imx8mp-tdx-linux/torizon-docker/1.0/rootfs/var/cache/dnf
Added oe-repo repo from /app/oe-core/build/tmp/work/verdin_imx8mp-tdx-linux/torizon-docker/1.0/oe-rootfs-repo
User-Agent: falling back to 'libdnf': could not detect OS or basearch
repo: using cache for: oe-repo
oe-repo: using metadata from Fri 24 Jan 2025 07:22:38 PM UTC.
No match for argument: secure-data
Error: Unable to find a match: secure-data

Here’s what my local.conf looks like:

IMAGE_INSTALL:append = " secure-data"
INHERIT += "tdx-tezi-data-partition"
INHERIT += "tdx-encrypted"

TDX_ENC_STORAGE_LOCATION = "/dev/mmcblk2p2"
TDX_TEZI_DATA_PARTITION_AUTOMOUNT = "1"

TDX_ENC_PRESERVE_DATA = "1"

TEZI_DATA_FILES = "secure_data_01.tar"

Here is my secure-data.bb

SRC_URI = "file://secure_data_01.tar;unpack=false"

inherit deploy

do_deploy() {
    # Ensure deployment directory exists
    install -d ${DEPLOY_DIR_IMAGE}

    # Deploy the tarball directly
    install -m 644 ${WORKDIR}/secure_data_01.tar ${DEPLOY_DIR_IMAGE}/secure_data_01.tar
}

Do you have any ideas on how I can fix this or ensure the secure data partition is included in the final image?

I’d really appreciate your help!

After that, I tried changing the partition name from mmcblk2p2 to mmcblk2p3 and flashed the image again (with secure boot enabled but still without blowing the efuse). That’s when I got the error I mentioned in my previous post.

Okay how did you “change the name here” exactly? Did you just set TDX_ENC_STORAGE_LOCATION = "/dev/mmcblk2p3"? Or did you do something else?

I don’t see anywhere in your previous posts or configurations how you created mmcblk2p3 with local.conf.

This configuration is generated automatically during the build. However, the final image file (torizon-docker-verdin-imx8mp-Tezi.tar) doesn’t include the secure_data_01 partition at all.

Hmm this seems like a bug in the Easy Installer creation process where the files TEZI_DATA_FILES are not being copied into the final tarball. Just to confirm though, if you manually copy your secure_data_01.tar into the final tarball, do your files get flashed properly into the data partition?

Meanwhile I can bring this bug up with our team.

While trying to resolve this with my .bb, I ran into the following issue during the build process:

So the complaint from yocto here is that Error: Unable to find a match: secure-data. Usually this implies there is something wrong with the recipe’s do_install method. Looking at your recipe there isn’t any do_install method which is probably the issue then. I think all/most recipes need a do_install of some kind.

Best Regards,
Jeremias