imx8ulp caam encryption suspend state error

[GiacomoE]

Platform: iMX8ULP
We are using caam module to encrypt the home partition of our device ad described in [AN12714](https://community.nxp.com/pwmxy87654/attachments/pwmxy87654/imx-processors/172311/1/AN12714_iMX%20En...). We create an encryption key the first time we encrypt the partition and we store the black key blob. On each reboot we extract the black key and we load it the kernel. The key we load in the kernel is a black key, that is a session key becoming invalid between power cycles.
When we put the system in suspend state and we resume it, we get errors from dm-crypt.
I think power to the caam module is disable in suspend state, so the encryption black key becomes invalid.
This seems a common scenario. What is the suggested way to overcome this issue ?

/home/root# ls /home/
/home/root# [ 120.036770] Aborting journal on device dm-3-8.
[ 120.041402] Buffer I/O error on dev dm-3, logical block 65536, lost sync page write
[ 120.049250] JBD2: I/O error when updating journal superblock for dm-3-8.
l
[ 123.246075] EXT4-fs error (device dm-3): ext4_journal_check_start:84: comm sh: Detected aborted journal
[ 123.255851] Buffer I/O error on dev dm-3, logical block 0, lost sync page write
[ 123.263340] EXT4-fs (dm-3): I/O error while writing superblock
[ 123.269292] EXT4-fs (dm-3): Remounting filesystem read-only

[csenatore]

as I known, 6.6.23 has already fixed this, ...

I've now tested this on the lf-6.18.2-1.00 linux-imx kernel without the patches provided by @joanxie. The bug described above still exists in the latest official NXP release.

If there really is a fix, it was never included in the IMX releases.

I have now taken the time to integrate the patches provided in the support thread into the 6.6 kernel based on lf-6.6.52-2.2.2

The first thing that stands out is that the patch was created for a significantly older kernel, as symbols like “CRYPTO_TFM_RES_BAD_KEY_LEN” only exist up to kernel 5.5. Was the patch really created for the 8ULP and the problem described above?

Since the patch was obviously created for kernel 5.5, is the implementation it contains even compatible with the CAAM driver for 6.6.x or 6.18.x?


After implementing the patches in my kernel, I also noticed that the following assignment in the “tb_skcipher_setkey” function needs to be adjusted:

- struct caam_ctx *ctx = crypto_skcipher_ctx(skcipher);
+ struct caam_ctx *ctx = crypto_skcipher_ctx_dma(skcipher);


These changes allow jrdev to be obtained. Otherwise, you get a NULL pointer and thus NULL pointer exceptions in the kernel.
In addition, a function reference for .skipher.op.do_onerequest had to be added in “driver_algs”; otherwise, dm_crypt does not call tb_skcipher_setkey at all.

After all these changes, I can run `dmsetup create`, but I get an ICV error for every I/O operation on the `dev/mapper` device. Therefore, the patch does not seem to be working.
CAAM Errorcode: 0x20000a1a

Do i missing something?

@joanxie  could you try the patches on the latest NXP release, or provide an update to the code for LF 6.6.x?
At least I can't get it to work this way.

Also, I’d be interested to know what happens during the CAAM suspension?

It seems as though the shared descriptor created by the skcipher_setkey() function is being lost. Can NXP confirm this?

A "umount" and "dmsetup remove" before suspend, and a new "dmsetup create" works just perfectly, so I assume this is an issue for the objects created in skcipher_setkey().

Is this a hardware bug in the processor, or is it simply a matter of forgetting to save and restore a state in the CAAM in driver-code?

[joanxie]

pls submit a ticket for this issue I need double check it, as I known, the latest bsp, don't need these patches, and has new mechanism, and I couldn't share these security patches in the public community

https://www.nxp.com/support/support:SUPPORTHOME?tid=sbmenu

[luca_cornacchia]

Hello @joanxie ,

thank you for your answer. What's the bsp /kernel version that fixes the issue?

We are currently using kernel 6.6.23 from Scarthgap release.

thank you,

Gianluca

[joanxie]

YES, this is exist issue on the old bsp, so what bsp version do you use? if could, pls upgrade it

[luca_cornacchia]

Hello @joanxie

thank you for your answer. What's the bsp or kernel version that fix the issue?
We are currently using kernel 6.6.23 from Scarthgap release.

thank you,
Gianluca

[joanxie]

as I known, 6.6.23 has already fixed this, but let me remind, when you test according to the AN, the step5 of chapter 3.2 usage, the command like

dmsetup -v create encrypted --table "0
$(blockdev --getsz /dev/loop0) crypt capi:tk(cbc(aes))-plain :32:caam_tk:seckey 0 /dev/loop0
0 1 sector_size:512

you need change the capi:tk to the capti:tb

[GiacomoE]

Hi Joanxie, thank you.
What is the purpose of using capi:tb instead of capi:tk ?
About the BSP update. Can you point out which patch is fixing the issue, so maybe we can pull only that change ?

[joanxie]

for these security information, I have mailed to you, pls check

[csenatore]

Hello everyone,

I also use the i.MX8ULP and used the CAAM module for an encrypted partition. The AN was followed for the setup.

I see exactly the same errors in the log when my device wakes up from suspend.

I used the 6.6.52.2.2.2 release.

I would be interested to know whether the problem has been resolved in general.

I also wonder what the difference is between capi:tk and capi:tb.

If I’m supposed to use capi:tb, I’d like to know what I need to keep in mind during setup. Do I need different commands?

I see that the 6.12 kernel has received patches related to CAAM and suspend for the 8ULP. But do I also need to consider other firmware components, such as the version of the FreeRTOS release, UPower, or the ELE-FW version?

[joanxie]

do you mind creating a ticket for this? I can send the patches to you

https://www.nxp.com/support/support:SUPPORTHOME?tid=sbmenu

click the "submit the ticket"

[csenatore]

Hi @joanxie,

Support Ticket is created: 00966449

[joanxie]

mailed to you already, pls check