topic Re: DM-Crypt with CAAM key Encrypted Filesystem Corrupt After Reboot in i.MX Processors

DM-Crypt with CAAM key Encrypted Filesystem Corrupt After Reboot

nsleung — Wed, 28 Sep 2022 22:56:04 GMT

Hello, I am using the iMX8M Mini SoC and am going through the app note (Rev 1 11/2020) Section 3.2 Usage (https://www.mouser.com/pdfDocs/AN12714.pdf). Kernel version is 5.4.70. I am able to complete everything (create tagged key, dummy image, ext4 filesystem, encrypt using dmsetup target crypt, etc). However, after the reboot and following the steps to mount the encrypted image fails. This is what is shown:

sudo mount /dev/mapper/encrypted /mnt/encrypted/ mount: /mnt/encrypted: wrong fs type, bad option, bad superblock on /dev/mapper/encrypted, missing codepage or helper program, or other error.

And when checking the integrity of the filesystem using fsck, it also reports bad superblock, leading me to believe something might be corrupted after rebooting.

e2fsck /dev/mapper/encrypted e2fsck 1.44.5 (15-Dec-2018) ext2fs_open2: Bad magic number in super-block e2fsck: Superblock invalid, trying backup blocks... e2fsck: Bad magic number in super-block while trying to open /dev/mapper/encrypted The superblock could not be read or does not describe a valid ext2/ext3/ext4 filesystem. If the device is valid and it really contains an ext2/ext3/ext4 filesystem (and not swap or ufs or something else), then the superblock is corrupt, and you might try running e2fsck with an alternate superblock: e2fsck -b 8193 <device> or e2fsck -b 32768 <device>

Any suggestions or thoughts would be appreciated!

Re: DM-Crypt with CAAM key Encrypted Filesystem Corrupt After Reboot

Harvey021 — Wed, 05 Oct 2022 04:44:29 GMT

Hi @nsleung

I've just followed up the guide to experiment it again. there is no such issue arise.

There would be probably required tools missed liek "coreutils keyutils lvm2 e2fsprogs-mke2fs util-linux"" which states in

section 8. Add required tools to build by editing conf/local.conf file and appending.

Best regards

Harvey

Re: DM-Crypt with CAAM key Encrypted Filesystem Corrupt After Reboot

nsleung — Tue, 11 Oct 2022 21:44:56 GMT

Thanks for the suggestion, I do have those additional utilities built in

Re: DM-Crypt with CAAM key Encrypted Filesystem Corrupt After Reboot

Harvey021 — Wed, 12 Oct 2022 04:08:18 GMT

Have you run caam-keygen import: # ./caam-keygen import /data/caam/randomkey.bb importKey

before running: # cat /data/caam/importKey | keyctl padd logon logkey2: @s

Because this key has to be re-injected every time it is powered up

Best regards

Harvey

Re: DM-Crypt with CAAM key Encrypted Filesystem Corrupt After Reboot

nsleung — Wed, 12 Oct 2022 17:34:49 GMT

Yes, I'm able to import the key and add to keyctl from blob after rebooting every time. I can also create the encrypted device mapper device using the same block device before the power cycle but when mounting, it will report 'corrupted filesystem'. Do I need to boot in Secure Mode? I don't believe I am doing that.

Re: DM-Crypt with CAAM key Encrypted Filesystem Corrupt After Reboot

lfant — Thu, 01 Feb 2024 13:36:23 GMT

Hello @nsleung ,

were you ever able to solve the problem? I see the exact same issue when using CAAM+dmcrypt on a iMX8MP running Yocto kirkstone & kernel 5.15.x

Re: DM-Crypt with CAAM key Encrypted Filesystem Corrupt After Reboot

woow — Wed, 11 Feb 2026 11:46:35 GMT

Hi NXP team,

We have an i.MX 8MP based device where a dm-crypt encrypted ext4 partition became unreadable after a power cycle. The exact same OS/image (same rootfs and provisioning process) is deployed across many devices, and those devices have definitely experienced power cycles without issue. We suspect a powerdown/up event may have triggered this failure on this particular device, but power cycling alone is not new in this fleet.

Unlock flow and exact commands:

# Only import key if keyhandle doesn't exist if [ ! -f /tmp/keyhandle ]; then # Import key using CAAM caam-keygen import /uboot/black_blob.bb keyhandle # Add key to kernel keyring cat /tmp/keyhandle | keyctl padd logon logkey: @s fi # Create dm-crypt mapping dmsetup -v create ${ENCRYPTED_NAME} --table "0 $(blockdev --getsz ${DEVICE}) crypt capi:tk(cbc(aes))-plain :36:logon:logkey: 0 ${DEVICE} 0 1 sector_size:512"

What we see:

dmsetup succeeds and mapping is ACTIVE
mount fails with “wrong fs type / bad superblock”
dmesg shows: EXT4-fs (dm-0): VFS: Can't find ext4 filesystem
e2fsck reports invalid superblock (no valid ext2/3/4 found)

We have verified the CAAM black blob on the device is still identical to what was flashed during manufacturing, so the key material itself does not appear to have changed. This makes us suspect either:

encrypted partition corruption due to power loss, or
a subtle CAAM/dm-crypt/driver issue that only manifests after reboot or power loss.

Environment:

Linux 6.6.23 (Yocto-based)
i.MX 8MP platform using CAAM key import
dm-crypt mapping created with capi:tk(cbc(aes))-plain, sector_size:512
ext4 filesystem
eMMC storage

Yocto layers / repo hashes used:

poky: 02eacd385eca7aa9cf25aaaa61427aa9c126e0bc
meta-openembedded: a72010b414ee3d73888ac9cb4e310e8f05e13aea
meta-arm: 8aa8a1f17f5b64bc691544f989f04fc83df98adb
meta-security: 11ea91192d43d7c2b0b95a93aa63ca7e73e38034
meta-timesys: b96d8de949939ad08094f71ed6ed4f88eaf41d5e
meta-virtualization: 1a547c0aa0d75c4143cbb66de6e653d51cdc8bda
meta-clang: 66414c17ae60e489bef9a97031323e92c247fbe1
meta-freescale: 41b923e59e048b9b2942ff737a4ddac386954c62
meta-freescale-3rdparty: 8b61684f0b1ba8bacdf3a69d993445e9791d4932
meta-freescale-distro: 158cc55b6ee30d09957b380859dba52c0f6af68d
meta-imx: 239073c47124f41f46581871afbde643f48d6a3b
meta-nxp-security-reference-design: 15d4eccdc503ea07634b869af0df7e4e2917ebf1

Questions for NXP:

Are there known issues with CAAM + dm-crypt (CBC-AES with capi:tk(cbc(aes))-plain) that can cause irrecoverable filesystem corruption after reboot/power loss?
Are there newer drivers or recommended crypt schemes/configs for CAAM-backed dm-crypt on i.MX 8MP that are more robust?
Since this is eMMC, do you have any recommendations for write-reliability settings, dm-crypt block size, flush behavior, mount options, or other mitigation techniques to reduce the chance of corruption after power loss?

If you need additional logs or details, I can provide them.

Thanks,