i.MX ProcessorsのトピックRe: i.MX6 CAAM : sm_test.c in 3.0.35 kernel broken

i.MX6 CAAM : sm_test.c in 3.0.35 kernel broken

deanmatsen — Wed, 29 Apr 2015 00:55:56 GMT

I wanted to use this file as an example of how to use black keys (and hopefully to extend that to black blobs).

I kept looking more and more closely at the example, because when it goes to use the black key to encrypt the data, it doesn't specify anything about that the key it wants to use is a black key. So why does it work? Does the CAAM automatically recognize a black key? The documentation doesn't say it does that.

Well, the explanation appears to be that it doesn't work. The sm_keystore_slot_encapsulate() and sm_keystore_decapsulate() calls fail with a generic "DMA error". So what happens is test loads in the clear text key, encapsulates it in place (which fails), then decapsulates it in place (which also fails), the result being that the clear text key is stored in the black key buffer. Then the procedure goes on to encrypt the data using the supposed black key (which explains why it works without specifying that it's a black key -- it's not a black key, and nobody tells the CAAM to load a black key, so of course it just does a normal encryption using the clear text key left in the buffer). Then it decrypts the data using the correct cleartext key, and reports "test match OK".

There is NO error checking on the encapsulate/decapsulate operations themselves. The tail end of int sm_keystore_slot_encapsulate() has the following:

}

jstat = sm_key_job(dev, encapdesc);

dma_unmap_single(dev, keymod_dma, keymodlen, DMA_TO_DEVICE);

kfree(encapdesc);

i.e. nothing ever checks "jstat". In my version, I added code to call caam_jr_strstatus(), which is how I determined the generic "DMA error".

As a result, the entire test "succeeds" because it uses cleartext keys throughout.

So my question is this: does anyone know how to make the sm_test.c example work the way it's supposed to, with actually using black keys? I really wanted to use it as a concrete example!

Re: i.MX6 CAAM : sm_test.c in 3.0.35 kernel broken

Yuri — Thu, 30 Apr 2015 03:33:35 GMT

Please look at the following threads in Community, that can help.

“Testing imx6 CAAM module in kernel”

https://community.freescale.com/message/379592#379592

“How to Create Blob”

https://community.freescale.com/message/341251#341251

Note, in order to generate a blob with the CAAM OTPMK, a secure boot with HAB should be

in closed config [...], otherwise in open config the blob will be created using the known CAAM

default master key.

Have a great day,
Yuri

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

Re: i.MX6 CAAM : sm_test.c in 3.0.35 kernel broken

Aymen_IRT — Tue, 07 Jul 2015 13:08:50 GMT

Hi,

I am using a Nitrogen6X board. I have tried sm_test.c in kernel 3.10.17 and I have got the same DMA errors as Dean. In addition, I have tried the SM patch proposed by Yuri:

ENGR00290444: Need to update CAAM driver with SM patches from STC

So, I added the sm_keystore_cover_key, sm_keystore_slot_import and sm_keystore_slot_export and slot_get_physical functions to sm_store.c. Then, I tried to make the sm_test.c work. However, I got the following error: caam 2100000.caam: can't detect secure memory base address which is related to a NULL res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "iobase_caam_sm"); defined in caam_sm_startup() function in sm_store.c. Normally, res must not be NULL in order to get a valid physical address.

Have you any idea concerning this issue?

Thank you for your help,

Best regards,

Aymen

Re: i.MX6 CAAM : sm_test.c in 3.0.35 kernel broken

deanmatsen — Tue, 07 Jul 2015 17:52:22 GMT

Aymen,

Yes, I did get it working after applying the patch.

It sounds like your board support is not registering the CAAM. Make sure your board C file is calling imx6q_add_imx_caam(). I see that is in the board-mx6q_sabrelite.c file, but it requires caam_enabled = 1. I took that out of my board C file and make it call this unconditionally (my board C file is a copy of the sabrelite one).

I did all of the patches, not just 290444. I doubt that will make a difference for you, but it might.

I still have the problem of my system hanging after a while if I use the CAAM for things like disk encryption or SSL. There are posted fixes for this, which (I think) can be found in

https://community.freescale.com/thread/303229

but I have not tried applying them yet. As such, for now I have CONFIG_CRYPTO_DEV_FSL_CAAM_CRYPTO_API disabled for now.

Re: i.MX6 CAAM : sm_test.c in 3.0.35 kernel broken

Aymen_IRT — Wed, 08 Jul 2015 07:26:53 GMT

Hi Dean,

Thank you for your reply.

Actually, I was also able to apply the patch to kernel v3.0.35 and successfully used secure blobs. However, I got the aforementioned problems when adapting the patch to kernel v3.10.17.

By the way, you are right concerning the activation of CAAM: either you do it by setting caam_enabled = 1 or by adding caam (or caam = 1) to your kernel bootargs.

Regards,

Aymen

Re: i.MX6 CAAM : sm_test.c in 3.0.35 kernel broken

Aymen_IRT — Fri, 10 Jul 2015 11:41:20 GMT

Hi,

Finally, I succeeded in applying the patch ENGR00290444 (Need to update CAAM driver with SM patches from STC) to kernel 3.10.17. The main difference between the patch for kernel 3.0.35 and kernel 3.10.17 consists in replacing the following block in function caam_sm_startup(struct platform_device *pdev) in sm_store.c:

struct resource *res;

res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "iobase_caam_sm");

if (res == NULL) {

dev_err(ctrldev, "can't detect secure memory base address\n");

return -ENOMEM;

}

By this code:

struct resource res;

ret = of_address_to_resource(np, 0, &res);

if (ret) {

dev_err(ctrldev, "can't detect secure memory base address\n");

kfree (smpriv);

return -ENOMEM;

}

Regards,

Aymen