Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!
Did you like my answer?
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.
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.
Configuration Check:
Ensure your local.conf file includes the necessary inheritance and variables:
Verify that TDX_ENC_STORAGE_LOCATION points to the correct partition you intend to encrypt.
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.
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.
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:
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.
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.
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.
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.
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?
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
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”.
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.
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.
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.
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.
