Tdx-encrypted with tdx-tezi-data-partition

Som: imx8mp
torizon version: 6.7.0
image: torizon-core-docker
distro: torizon
using the TEZI installer to program the SOM

I’m trying to create an encrypted partition on the emmc following instructions from meta-toradex-security

I started by just creating a data partition in the emmc

# local.conf
INHERIT += "tdx-tezi-data-partition"

This works exactly as expected.

Then I went to add encryption

# local.conf
INHERIT += "tdx-encrypted"
TDX_ENC_STORAGE_LOCATION = "/dev/mmcblk2p2"

This OS fails to boot with the following error.

Starting version 250.5+
[ TIME ] Timed out waiting for device /dev/disk/by-label/DATA.
[DEPEND] Dependency failed for /data.
[DEPEND] Dependency failed for Local File Systems.
You are in emergency mode. After logging in, type "journalctl -xb" to view
system logs, "systePress Enter for maintenance
(or press Control-D to continue): 

Going into maintenance mode:

sh-5.1# ls /dev/disk/by-label/
DATA  otaroot
sh-5.1# 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 
  `-encdata  253:0    0  7.4G  0 dm   /run/encdata
mmcblk2boot0 179:32   0 31.5M  1 disk 
mmcblk2boot1 179:64   0 31.5M  1 disk 

I figured the easiest way out of this predicament is to disable auto mounting the data partition

# local.conf
TDX_TEZI_DATA_PARTITION_AUTOMOUNT = "0"

Now, the system will boot, but the encrypted data does not persist between reboots. Every time the system boots it gets to the point where it checks for an existing mapper device and doesn’t find it so it reformats the whole partition.

This seems like a pretty standard use case, so I have to imagine there’s a config line somewhere that I’m not understanding.


Update:
I decided to check if the encrypted data would remain if I restarted the encryption service

systemctl restart tdx-enc-handler.service

# journalctl indicates the existing partition was mounted
 tdx-enc.sh[1083]: caam: Setting up partition with dm-crypt...
 tdx-enc.sh[1095]: Name:              encdata
 tdx-enc.sh[1095]: State:             ACTIVE
 tdx-enc.sh[1095]: Read Ahead:        256
 tdx-enc.sh[1095]: Tables present:    LIVE
 tdx-enc.sh[1095]: Open count:        0
 tdx-enc.sh[1095]: Event number:      0
 tdx-enc.sh[1095]: Major, minor:      253, 0
 tdx-enc.sh[1095]: Number of targets: 1
 tdx-enc.sh[1083]: caam: Mounting encrypted partition...
 tdx-enc.sh[1104]: /dev/mapper/encdata: UUID="c475c16a-8177-478c-9f72-983871f91f6b" BLOCK_SIZE="4096" TYPE="ext4"
 tdx-enc.sh[1083]: caam: Data preservation is not enabled
 tdx-enc.sh[1083]: caam: Success!

However, adding data to the partition results in errors

echo hello > /run/encdata/test.txt
systemctl restart tdx-enc-handler.service

# journalctl output
 systemd[1]: Stopping Encryption handler for Toradex modules...
 tdx-enc.sh[1145]: caam: Unmounting dm-crypt partition...
 tdx-enc.sh[1145]: caam: Removing dm-crypt partition...
 tdx-enc.sh[1147]: device-mapper: remove ioctl on encdata  failed: Device or resource busy
 tdx-enc.sh[1147]: Command failed.
 tdx-enc.sh[1145]: caam: Removing key from kernel keyring...
 tdx-enc.sh[1145]: caam: Success!
 systemd[1]: tdx-enc-handler.service: Deactivated successfully.
 systemd[1]: Stopped Encryption handler for Toradex modules.
 systemd[1]: Starting Encryption handler for Toradex modules...
 tdx-enc.sh[1150]: caam: Preparing and checking system (generic)...
 tdx-enc.sh[1150]: caam: Blocks to be encrypted: 15540224...
 tdx-enc.sh[1150]: caam: Reserved blocks: 0...
 tdx-enc.sh[1150]: caam: Preparing and checking system (caam)...
 tdx-enc.sh[1150]: caam: Setting up encryption key for CAAM backend...
 tdx-enc.sh[1150]: caam: Configuring key in kernel keyring (type=trusted keyname=tdxenc)...
 tdx-enc.sh[1150]: caam: Encrypted key exists. Importing it...
 tdx-enc.sh[1159]: 561625088
 tdx-enc.sh[1150]: caam: Data preservation is not enabled
 tdx-enc.sh[1150]: caam: Setting up partition with dm-crypt...
 tdx-enc.sh[1162]: device-mapper: create ioctl on encdata  failed: Device or resource busy
 tdx-enc.sh[1162]: Command failed.
 tdx-enc.sh[1150]: caam: ERROR: Error setting up dm-crypt partition!
 systemd[1]: tdx-enc-handler.service: Main process exited, code=exited, status=1/FAILURE
 systemd[1]: tdx-enc-handler.service: Failed with result 'exit-code'.
 systemd[1]: Failed to start Encryption handler for Toradex modules.

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

Did you like my answer?

:+1: :-1:


Based on the context provided, it seems like you are trying to create an encrypted data partition on the eMMC using the meta-toradex-security layer, but are encountering issues with the persistence of the encrypted data across reboots.

From the information given, it appears that the system is not correctly recognizing or preserving the encrypted data partition between reboots. This could be due to the way the encrypted partition is being set up or mounted.

Here are a few suggestions that might help resolve the issue:

  1. Check the Encryption Setup: Ensure that the encryption setup is correctly configured in your local.conf. The TDX_ENC_STORAGE_LOCATION should point to the correct partition, and any necessary encryption keys or passphrases should be correctly handled.

  2. Verify the Mounting Process: Since you disabled auto-mounting with TDX_TEZI_DATA_PARTITION_AUTOMOUNT = "0", ensure that the encrypted partition is being manually mounted correctly after boot. You might need to set up a script or systemd service to handle this.

  3. Persistence of Encryption Keys: Make sure that the encryption keys or passphrases are stored in a persistent manner, so they are available across reboots. This might involve storing them in a secure location that is accessible during the boot process.

  4. Check System Logs: Use journalctl -xb to check the system logs for any errors or warnings related to the encryption or mounting process. This might provide more insight into what is going wrong.

  5. Consult Documentation: Review the meta-toradex-security documentation to ensure that all necessary steps and configurations are being followed.

If these suggestions do not resolve the issue, it might be necessary to consult more detailed documentation or seek support from Toradex for further assistance.

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

OSTree | Toradex Developer Center.

Greetings @roedy,

Just to start by gathering more information. First of all, are these the only configurations you have in your local.conf when you saw this issue?:

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

Or, did you set anything else?

Furthermore what were the hashes of the meta-layers used in your build for this?

Best Regards,
Jeremias

I started with the 6.7.0 tag from the toradex manfest, but I had a build error from meta-toradex-security

ERROR: Layer 'meta-toradex-security' depends on layer 'toradex-ti-layer', but this layer is not enabled in your configuration

I ended up pulling the latest kirkstone branch. I could try this again with one of the 6.8.0 branches. Output from bitbake:

meta-toradex-torizon = "HEAD:8e454fb6385b100c718e26cbfa45f90931bccec3"
meta-toradex-security = "kirkstone-6.x.y:7faef012756058d91a6f15ab099f3bdc0be6974e"
meta-toradex-distro  = "HEAD:7212583d894bbf5501fb1ff20c131ce485b4e4b7"
meta-toradex-bsp-common = "HEAD:0c7948071f2cd325b23b53be543f0262f9483a7b"
meta-ml              = "HEAD:ca68ab5d25322b51f54564275c84ab8de3c74ea6"
meta-oe              
meta-networking      
meta-filesystems     
meta-python          
meta-perl            = "HEAD:8e297cdc841c6cad34097f00a6903ba25edfc153"
meta-virtualization  = "HEAD:8b356b91ed0d4bcab72350a2ddcef880f4fa5c26"
meta-updater         = "HEAD:6c4feab2db70cb0c8ddce7e18dc7b851ad475b32"
meta-toradex-nxp     = "HEAD:83fac5a88f89eaf66c57b0ceb7cb27ffe8818285"
meta-freescale       = "HEAD:4c81b4161b99698b03332842b588dd8235ac47e4"
meta-freescale-3rdparty = "HEAD:9e94b64bdfebcf7bfdf2af6447cec866a4efa814"
meta-yocto-bsp       
meta-poky            = "HEAD:6518f291d692997632304451695b6c194fec6fa6"
meta-security        = "HEAD:353078bc06c8b471736daab6ed193e30d533d1f1"
meta                 = "HEAD:ab2649ef6c83f0ae7cac554a72e6bea4dcda0e99"

In local.conf, the settings I ended up with related to this issue are

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

Thank you for providing the additional information. Please allow us some time to discuss and investigate this on our side.

Best Regards,
Jeremias

I did a quick test against our latest 6.8 build manifest. Using a similar local.conf setup to the one you shared I was able to reproduce a similar result on my device:

Starting kernel ...

[    1.048914] rtc-ds1307 0-0032: hctosys: unable to read the hardware clock
[    1.060374] pca953x 3-0021: failed writing register
[    1.071885] clk: failed to reparent hsio_axi to sys_pll2_500m: -16
[    1.088395] clk: failed to reparent hsio_axi to sys_pll2_500m: -16
[    1.098971] clk: failed to reparent hsio_axi to sys_pll2_500m: -16
[    2.378545] +V3.3_SW: Underflow of regulator enable count
[    2.614041] [drm:drm_bridge_attach] *ERROR* failed to attach bridge /soc@0/bus@32c00000/mipi_dsi@32e60000 to encoder DSI-37: -517
[    2.625849] imx_sec_dsim_drv 32e60000.mipi_dsi: Failed to attach bridge: 32e60000.mipi_dsi
[    2.634118] imx_sec_dsim_drv 32e60000.mipi_dsi: failed to bind sec dsim bridge: -517
Starting version 250.5+
[FAILED] Failed to mount /data.
[DEPEND] Dependency failed for Local File Systems.
You are in emergency mode. After logging in, type "journalctl -xb" to view
system logs, "syste
Cannot open access to console, the root account is locked.
See sulogin(8) man page for more details.

Seems like there’s some synchronization issues with the startup services in Torizon OS that mount the data partition and the services that handle the encryption. I’ll report this to our technical team for further work on a possible solution. Thank you for bringing this to our attention.

Best Regards,
Jeremias

1 Like

Hi Jeremias, I was just wondering if you had an update on this?

No updates yet. I submitted a ticket to our R&D team for further investigation and possible fixing. The ticket was submitted during the middle of our team’s sprint cycle, so they haven’t had a chance to look into it yet.

Best Regards,
Jeremias

Hi Jeremias, just checking in if you have any updates on this

The team is currently looking into the issue as of now. They have reproduced the OS boot error as well as the issue with the encrypted data loss. They have a pretty good idea of what is causing these issues. They’re discussing how best to resolve these issue and then plan to submit a fix when it’s been tested and ready.

Best Regards,
Jeremias

Thank you for the update

Alright the team has submitted and merged some changes that should resolve the issue you were observing here. These changes can be seen here: Allow tdx-encrypted to be used with Torizon (plus improvements) by rborn-tx · Pull Request #83 · toradex/meta-toradex-security · GitHub

There’s a follow-up for Kirkstone that should be merged shortly as seen here: Allow tdx-encrypted to be used with Torizon (plus improvements) - kirkstone by rborn-tx · Pull Request #84 · toradex/meta-toradex-security · GitHub

Give this a try when you have a chance and let me know if the changes help with your use-case.

Best Regards,
Jeremias

That is amazing news, I’ll try it out! Thanks