Re: CAAM and IMA/EVM : caam_rsa_enc: DECO: desc idx 7: Protocol Size Error
Hi Horia, On Fri, Apr 13, 2018 at 3:18 AM, Horia Geantă wrote: > Stripping should happen before set_rsa_pub_pdb() is called since the Protocol > Data Block contains the input length that is used by the accelerator: > pdb->f_len = req->src_len; > > It should probably be moved at the top of rsa_edesc_alloc(). That did the trick, thanks! > Ideally stripping would avoid copying data (and memory allocation for > temporary > buffers). I will try to optimize this aspect and will post a proper patch. Martin, Before I try to optimize it, I would like to share the patch (generated against linux-next) so that you can try it in your IMA usecase: http://code.bulix.org/n77z3e-318473 Does it work for you? Thanks
Re: CAAM and IMA/EVM : caam_rsa_enc: DECO: desc idx 7: Protocol Size Error
On 4/13/2018 3:12 AM, Fabio Estevam wrote: > Hi Horia, > > On Thu, Apr 12, 2018 at 4:12 AM, Horia Geantă wrote: > >> Yes, driver needs to strip off leading zeros from input data before feeding >> it >> to the accelerator. >> I am working at a fix. > > I was able to to strip off the leading zeros from input data as you suggested. > > My changes are like this at the moment: > [snip] > but still get the original error as shown below. > > Any ideas? > Stripping should happen before set_rsa_pub_pdb() is called since the Protocol Data Block contains the input length that is used by the accelerator: pdb->f_len = req->src_len; It should probably be moved at the top of rsa_edesc_alloc(). Ideally stripping would avoid copying data (and memory allocation for temporary buffers). Horia
Re: CAAM and IMA/EVM : caam_rsa_enc: DECO: desc idx 7: Protocol Size Error
Hi Horia,
On Thu, Apr 12, 2018 at 4:12 AM, Horia Geantă wrote:
> Yes, driver needs to strip off leading zeros from input data before feeding it
> to the accelerator.
> I am working at a fix.
I was able to to strip off the leading zeros from input data as you suggested.
My changes are like this at the moment:
diff --git a/drivers/crypto/caam/caampkc.c b/drivers/crypto/caam/caampkc.c
index 7a897209..ef9b9c2 100644
--- a/drivers/crypto/caam/caampkc.c
+++ b/drivers/crypto/caam/caampkc.c
@@ -500,6 +500,14 @@ static int set_rsa_priv_f3_pdb(struct
akcipher_request *req,
return -ENOMEM;
}
+static void caam_rsa_drop_leading_zeros(const u8 **ptr, size_t *nbytes)
+{
+ while (!**ptr && *nbytes) {
+ (*ptr)++;
+ (*nbytes)--;
+ }
+}
+
static int caam_rsa_enc(struct akcipher_request *req)
{
struct crypto_akcipher *tfm = crypto_akcipher_reqtfm(req);
@@ -507,7 +515,10 @@ static int caam_rsa_enc(struct akcipher_request *req)
struct caam_rsa_key *key = &ctx->key;
struct device *jrdev = ctx->dev;
struct rsa_edesc *edesc;
+ void *buffer;
+ const u8 *temp;
int ret;
+ size_t len;
if (unlikely(!key->n || !key->e))
return -EINVAL;
@@ -531,6 +542,46 @@ static int caam_rsa_enc(struct akcipher_request *req)
/* Initialize Job Descriptor */
init_rsa_pub_desc(edesc->hw_desc, &edesc->pdb.pub);
+ buffer = kmalloc(req->src_len, GFP_ATOMIC);
+ if (!buffer)
+ return -ENOMEM;
+
+ temp = kmalloc(req->src_len, GFP_ATOMIC);
+ if (!temp)
+ return -ENOMEM;
+
+ sg_copy_to_buffer(req->src, sg_nents(req->src),
+ buffer, req->src_len);
+
+ temp = (u8 *)buffer;
+ len = req->src_len;
+ if (temp[0] != 0)
+ goto jr_enqueue;
+ else
+ pr_err("*** Leading zero found\n");
+
+ pr_err("*** Original buffer \n");
+ pr_err("* temp[0] = 0x%x\n", temp[0]);
+ pr_err("* temp[1] = 0x%x\n", temp[1]);
+ pr_err("* temp[2] = 0x%x\n", temp[2]);
+ pr_err("* temp[3] = 0x%x\n", temp[3]);
+ pr_err("* Original size: %d\n", req->src_len);
+
+ caam_rsa_drop_leading_zeros(&temp, &len);
+ if (!temp)
+ return -ENOMEM;
+
+ pr_err("*** Buffer after dropping lead zero \n");
+ pr_err("* temp[0] = 0x%x\n", temp[0]);
+ pr_err("* temp[1] = 0x%x\n", temp[1]);
+ pr_err("* temp[2] = 0x%x\n", temp[2]);
+ pr_err("* temp[3] = 0x%x\n", temp[3]);
+
+ req->src_len = req->src_len - 1;
+ pr_err("* Final size: %d\n", req->src_len);
+ sg_copy_from_buffer(req->src, sg_nents(req->src),
+ (void *)temp, req->src_len);
+jr_enqueue:
ret = caam_jr_enqueue(jrdev, edesc->hw_desc, rsa_pub_done, req);
if (!ret)
return -EINPROGRESS;
@@ -683,14 +734,6 @@ static void caam_rsa_free_key(struct caam_rsa_key *key)
memset(key, 0, sizeof(*key));
}
-static void caam_rsa_drop_leading_zeros(const u8 **ptr, size_t *nbytes)
-{
- while (!**ptr && *nbytes) {
- (*ptr)++;
- (*nbytes)--;
- }
-}
-
/**
* caam_read_rsa_crt - Used for reading dP, dQ, qInv CRT members.
* dP, dQ and qInv could decode to less than corresponding p, q length, as the
but still get the original error as shown below.
Any ideas?
Thanks
[2.985258] cfg80211: Loading compiled-in X.509 certificates for
regulatory database
[2.998105] *** Leading zero found
[3.002100] *** Original buffer
[3.005734] * temp[0] = 0x0
[3.009147] * temp[1] = 0x87
[3.012440] * temp[2] = 0x3
[3.015634] * temp[3] = 0xda
[3.019036] * Original size: 257
[3.022675] *** Buffer after dropping lead zero
[3.027805] * temp[0] = 0x87
[3.031092] * temp[1] = 0x3
[3.034286] * temp[2] = 0xda
[3.037673] * temp[3] = 0xf2
[3.040960] * Final size: 256
[3.044501] caam_jr 2142000.jr1: 4789: DECO: desc idx 7:
Protocol Size Error - A protocol has seen an error in size. When
running RSA, pdb size N < (size of F) when no formatting is used; or
pdb si
ze N < (F + 11) when formatting is used.
[3.067864] [ cut here ]
[3.072600] WARNING: CPU: 0 PID: 1 at
crypto/asymmetric_keys/public_key.c:148
public_key_verify_signature+0x27c/0x2b0
[3.083390] Modules linked in:
[3.086542] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
4.16.0-next-20180410-5-g5e59986-dirty #323
[3.095726] Hardware name: Freescale i.MX6 Ultralite (Device Tree)
[3.101954] Backtrace:
[3.104482] [] (dump_backtrace) from []
(show_stack+0x18/0x1c)
[3.112113] r7: r6:6153 r5: r4:c107ae78
[3.117840] [] (show_stack) from []
(dump_stack+0xb4/0xe8)
[3.125126] [] (dump_stack) from [] (__warn+0x104/0x130)
Re: CAAM and IMA/EVM : caam_rsa_enc: DECO: desc idx 7: Protocol Size Error
On 4/11/2018 8:26 PM, Fabio Estevam wrote: > Hi Horia, > > On Wed, Apr 11, 2018 at 7:15 AM, Horia Geantă wrote: > >> You'd want to make sure rsa is offloaded to caam in this case - check in >> /proc/crypto. >> IIRC there are some i.mx parts that don't have support for Public Key >> acceleration (PKHA). > > PKHA is present on mx6ul and not present on mx6q. > > mx6uq uses the generic rsa driver and handles the certificate correctly. > > mx6ul uses pkcs1pad(rsa-caam,sha256) and it fails to handle the certificate. > > So that explains the different behavior of mx6q versus mx6ul. > Thanks for confirming my guess. > Any ideas as to how to fix rsa-caam? > Yes, driver needs to strip off leading zeros from input data before feeding it to the accelerator. I am working at a fix. Horia
Re: CAAM and IMA/EVM : caam_rsa_enc: DECO: desc idx 7: Protocol Size Error
Hi Horia, On Wed, Apr 11, 2018 at 7:15 AM, Horia Geantă wrote: > You'd want to make sure rsa is offloaded to caam in this case - check in > /proc/crypto. > IIRC there are some i.mx parts that don't have support for Public Key > acceleration (PKHA). PKHA is present on mx6ul and not present on mx6q. mx6uq uses the generic rsa driver and handles the certificate correctly. mx6ul uses pkcs1pad(rsa-caam,sha256) and it fails to handle the certificate. So that explains the different behavior of mx6q versus mx6ul. Any ideas as to how to fix rsa-caam? Thanks
Re: CAAM and IMA/EVM : caam_rsa_enc: DECO: desc idx 7: Protocol Size Error
On Wed, Apr 11, 2018 at 11:58 AM, Horia Geantă wrote: > On 4/11/2018 1:36 AM, James Bottomley wrote: >> On Tue, 2018-04-10 at 23:01 +0100, Martin Townsend wrote: >>> Using openssl to get the signature in my x509 cert >>> >>>Signature Algorithm: sha256WithRSAEncryption >>> 68:82:cc:5d:f9:ee:fb:1a:77:72:a6:a9:c6:4c:cc:d7:f6:2a: >>> 17:a5:db:bf:5a:2b:8d:39:60:dc:a0:93:39:45:0f:bc:a7:e8: >>> 7f:6c:06:84:2d:f3:c1:94:0a:60:56:1c:50:78:dc:34:d1:87: >>> >>> So there's an extra 0x00 and the signature is 257 bytes so I guess >>> this is upsetting CAAM, just need to work out where it's coming from, >>> or whether it's valid and CAAM should be handling it. >> >> A signature is just a bignum so leading zeros are permitted because >> it's the same numeric value; however, there are normalization >> procedures that require stripping the leading zeros, say before doing a >> hash or other operation which would be affected by them. >> >> CAAM should definitely handle it on the "be liberal in what you accept" >> principle. The kernel should probably remove the leading zeros on the >> "be conservative in what you do" part of the same principle. >> > Looking at the generic SW implementation (crypto/rsa.c, rsa_verify()), leading > zeros are removed: > s = mpi_read_raw_from_sgl(req->src, req->src_len); > > CAAM implementation of rsa is not doing this (though it is removing leading > zeros when reading public, private keys). > It has to be fixed. Thanks for the report. > Do you have any idea when a fix will be available? I'm happy to test on my setup here. >>> I notice that in my stack trace I have pkcs1pad_verify which >>> suggests some sort of padding? >> >> Yes, RSA has various forms of padding because the information being >> encrypted is usually much smaller than the encryption unit; PKCS1 is >> the most common (although its now deprecated in favour of OAEP because >> of all the padding oracle problems). >> > RSA padding has been intentionally added as a template, wrapping "textbook" > (raw) RSA primitives. > For PKCS#1 v1.5, a template instantiation is called pkcs1pad(rsa, hash_alg). > > Currently in kernel the only supported RSA padding scheme is PKCS#1 v1.5. > When implemented, another scheme - for e.g. OAEP - would be added in a similar > way, as a template: oaep(rsa, ...). > > Horia
Re: CAAM and IMA/EVM : caam_rsa_enc: DECO: desc idx 7: Protocol Size Error
Hi James, On Tue, Apr 10, 2018 at 11:36 PM, James Bottomley wrote: > On Tue, 2018-04-10 at 23:01 +0100, Martin Townsend wrote: >> Using openssl to get the signature in my x509 cert >> >>Signature Algorithm: sha256WithRSAEncryption >> 68:82:cc:5d:f9:ee:fb:1a:77:72:a6:a9:c6:4c:cc:d7:f6:2a: >> 17:a5:db:bf:5a:2b:8d:39:60:dc:a0:93:39:45:0f:bc:a7:e8: >> 7f:6c:06:84:2d:f3:c1:94:0a:60:56:1c:50:78:dc:34:d1:87: >> >> So there's an extra 0x00 and the signature is 257 bytes so I guess >> this is upsetting CAAM, just need to work out where it's coming from, >> or whether it's valid and CAAM should be handling it. > > A signature is just a bignum so leading zeros are permitted because > it's the same numeric value; however, there are normalization > procedures that require stripping the leading zeros, say before doing a > hash or other operation which would be affected by them. > > CAAM should definitely handle it on the "be liberal in what you accept" > principle. The kernel should probably remove the leading zeros on the > "be conservative in what you do" part of the same principle. > >> I notice that in my stack trace I have pkcs1pad_verify which >> suggests some sort of padding? > > Yes, RSA has various forms of padding because the information being > encrypted is usually much smaller than the encryption unit; PKCS1 is > the most common (although its now deprecated in favour of OAEP because > of all the padding oracle problems). > > James > Thanks for the info, so the leading zero needs to be removed.
Re: CAAM and IMA/EVM : caam_rsa_enc: DECO: desc idx 7: Protocol Size Error
On 4/11/2018 1:36 AM, James Bottomley wrote: > On Tue, 2018-04-10 at 23:01 +0100, Martin Townsend wrote: >> Using openssl to get the signature in my x509 cert >> >> Signature Algorithm: sha256WithRSAEncryption >> 68:82:cc:5d:f9:ee:fb:1a:77:72:a6:a9:c6:4c:cc:d7:f6:2a: >> 17:a5:db:bf:5a:2b:8d:39:60:dc:a0:93:39:45:0f:bc:a7:e8: >> 7f:6c:06:84:2d:f3:c1:94:0a:60:56:1c:50:78:dc:34:d1:87: >> >> So there's an extra 0x00 and the signature is 257 bytes so I guess >> this is upsetting CAAM, just need to work out where it's coming from, >> or whether it's valid and CAAM should be handling it. > > A signature is just a bignum so leading zeros are permitted because > it's the same numeric value; however, there are normalization > procedures that require stripping the leading zeros, say before doing a > hash or other operation which would be affected by them. > > CAAM should definitely handle it on the "be liberal in what you accept" > principle. The kernel should probably remove the leading zeros on the > "be conservative in what you do" part of the same principle. > Looking at the generic SW implementation (crypto/rsa.c, rsa_verify()), leading zeros are removed: s = mpi_read_raw_from_sgl(req->src, req->src_len); CAAM implementation of rsa is not doing this (though it is removing leading zeros when reading public, private keys). It has to be fixed. Thanks for the report. >> I notice that in my stack trace I have pkcs1pad_verify which >> suggests some sort of padding? > > Yes, RSA has various forms of padding because the information being > encrypted is usually much smaller than the encryption unit; PKCS1 is > the most common (although its now deprecated in favour of OAEP because > of all the padding oracle problems). > RSA padding has been intentionally added as a template, wrapping "textbook" (raw) RSA primitives. For PKCS#1 v1.5, a template instantiation is called pkcs1pad(rsa, hash_alg). Currently in kernel the only supported RSA padding scheme is PKCS#1 v1.5. When implemented, another scheme - for e.g. OAEP - would be added in a similar way, as a template: oaep(rsa, ...). Horia
Re: CAAM and IMA/EVM : caam_rsa_enc: DECO: desc idx 7: Protocol Size Error
On 4/11/2018 5:21 AM, Fabio Estevam wrote: > Hi Martin, > > On Tue, Apr 10, 2018 at 7:01 PM, Martin Townsend > wrote: > >> A hexdump of the signature reveals a 0x00 at the start > > Yes, same is happening here on my mx6ul evk running linux-next: > [snip] > > However, the same kernel running on a mx6 board does not give the > "Protocol Size Error": > You'd want to make sure rsa is offloaded to caam in this case - check in /proc/crypto. IIRC there are some i.mx parts that don't have support for Public Key acceleration (PKHA). Horia
Re: CAAM and IMA/EVM : caam_rsa_enc: DECO: desc idx 7: Protocol Size Error
Hi Martin,
On Tue, Apr 10, 2018 at 7:01 PM, Martin Townsend
wrote:
> A hexdump of the signature reveals a 0x00 at the start
Yes, same is happening here on my mx6ul evk running linux-next:
[2.990651] cfg80211: Loading compiled-in X.509 certificates for
regulatory database
[2.999046] signature: 00 87 03 da f2 82 c2 dd af 7c 44 2f
86 d3 5f 4c .|D/.._L
[3.008213] signature0010: 93 48 b9 fe 07 17 bb 21 f7 25 23 4e
aa 22 0c 16 .H.!.%#N."..
[3.017069] signature0020: b9 73 ae 9d 46 7c 75 d9 c3 49 57 47
bf 33 b7 97 .s..F|u..IWG.3..
[3.026064] signature0030: ec f5 40 75 c0 46 22 f0 a0 5d 9c 79
13 a1 ff b8 ..@u.F"..].y
[3.035049] signature0040: a3 2f 7b 8e 06 3f c8 b6 e4 6a 28 f2
34 5c 23 3f ./{..?...j(.4\#?
[3.043994] signature0050: 32 c0 e6 ad 0f ac cf 55 74 47 73 d3
01 85 b7 0b 2..UtGs.
[3.052941] signature0060: 22 56 24 7d 9f 09 a9 0e 86 9e 37 5b
9c 6d 02 d9 "V$}..7[.m..
[3.061879] signature0070: 8c c8 50 6a e2 59 f3 16 06 ea b2 42
b5 58 fe ba ..Pj.Y.B.X..
[3.070813] signature0080: d1 81 57 1a ef b2 38 88 58 f6 aa c4
2e 8b 5a 27 ..W...8.X.Z'
[3.079742] signature0090: e4 a5 e8 a4 ca 67 5c ac 72 67 c3 6f
13 c3 2d 35 .g\.rg.o..-5
[3.088669] signature00a0: 79 d7 8a e7 f5 d4 21 30 4a d5 f6 a3
d9 79 56 f2 y.!0JyV.
[3.097512] signature00b0: 0f 10 f7 7d d0 51 93 2f 47 f8 7d 4b
0a 84 55 12 ...}.Q./G.}K..U.
[3.106437] signature00c0: 0a 7d 4e 3b 1f 2b 2f fc 28 b3 69 34
e1 80 80 bb .}N;.+/.(.i4
[3.115366] signature00d0: e2 af b9 d6 30 f1 1d 54 87 23 99 9f
51 03 4c 45 0..T.#..Q.LE
[3.124292] signature00e0: 7d 02 65 73 ab fd cf 94 cc 0d 3a 60
fd 3c 14 2f }.es..:`.<./
[3.133238] signature00f0: 16 33 a9 21 1f cb 50 b1 8f 03 ee a0
66 a9 16 79 .3.!..P.f..y
[3.142189] signature0100: 14
.
[3.155013] caam_jr 2142000.jr1: 4789: DECO: desc idx 7:
Protocol Size Error - A protocol has seen an error in size. When
running RSA, pdb size N < (size of F) when no formatting is used; or
pdb si
ze N < (F + 11) when formatting is used.
However, the same kernel running on a mx6 board does not give the
"Protocol Size Error":
[2.654244] cfg80211: Loading compiled-in X.509 certificates for
regulatory database
[2.662221] signature: 00 87 03 da f2 82 c2 dd af 7c 44 2f
86 d3 5f 4c .|D/.._L
[2.671221] signature0010: 93 48 b9 fe 07 17 bb 21 f7 25 23 4e
aa 22 0c 16 .H.!.%#N."..
[2.680082] signature0020: b9 73 ae 9d 46 7c 75 d9 c3 49 57 47
bf 33 b7 97 .s..F|u..IWG.3..
[2.688893] signature0030: ec f5 40 75 c0 46 22 f0 a0 5d 9c 79
13 a1 ff b8 ..@u.F"..].y
[2.697750] signature0040: a3 2f 7b 8e 06 3f c8 b6 e4 6a 28 f2
34 5c 23 3f ./{..?...j(.4\#?
[2.706604] signature0050: 32 c0 e6 ad 0f ac cf 55 74 47 73 d3
01 85 b7 0b 2..UtGs.
[2.715460] signature0060: 22 56 24 7d 9f 09 a9 0e 86 9e 37 5b
9c 6d 02 d9 "V$}..7[.m..
[2.724323] signature0070: 8c c8 50 6a e2 59 f3 16 06 ea b2 42
b5 58 fe ba ..Pj.Y.B.X..
[2.733182] signature0080: d1 81 57 1a ef b2 38 88 58 f6 aa c4
2e 8b 5a 27 ..W...8.X.Z'
[2.742032] signature0090: e4 a5 e8 a4 ca 67 5c ac 72 67 c3 6f
13 c3 2d 35 .g\.rg.o..-5
[2.750883] signature00a0: 79 d7 8a e7 f5 d4 21 30 4a d5 f6 a3
d9 79 56 f2 y.!0JyV.
[2.759737] signature00b0: 0f 10 f7 7d d0 51 93 2f 47 f8 7d 4b
0a 84 55 12 ...}.Q./G.}K..U.
[2.768543] signature00c0: 0a 7d 4e 3b 1f 2b 2f fc 28 b3 69 34
e1 80 80 bb .}N;.+/.(.i4
[2.777403] signature00d0: e2 af b9 d6 30 f1 1d 54 87 23 99 9f
51 03 4c 45 0..T.#..Q.LE
[2.786259] signature00e0: 7d 02 65 73 ab fd cf 94 cc 0d 3a 60
fd 3c 14 2f }.es..:`.<./
[2.795110] signature00f0: 16 33 a9 21 1f cb 50 b1 8f 03 ee a0
66 a9 16 79 .3.!..P.f..y
[2.803957] signature0100: 14
.
[2.816788] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
[2.824922] platform regulatory.0: Direct firmware load for
regulatory.db failed with error -2
[2.829396] ALSA device list:
[2.833904] cfg80211: failed to load regulatory.db
Re: CAAM and IMA/EVM : caam_rsa_enc: DECO: desc idx 7: Protocol Size Error
On Tue, 2018-04-10 at 23:01 +0100, Martin Townsend wrote: > Using openssl to get the signature in my x509 cert > > Signature Algorithm: sha256WithRSAEncryption > 68:82:cc:5d:f9:ee:fb:1a:77:72:a6:a9:c6:4c:cc:d7:f6:2a: > 17:a5:db:bf:5a:2b:8d:39:60:dc:a0:93:39:45:0f:bc:a7:e8: > 7f:6c:06:84:2d:f3:c1:94:0a:60:56:1c:50:78:dc:34:d1:87: > > So there's an extra 0x00 and the signature is 257 bytes so I guess > this is upsetting CAAM, just need to work out where it's coming from, > or whether it's valid and CAAM should be handling it. A signature is just a bignum so leading zeros are permitted because it's the same numeric value; however, there are normalization procedures that require stripping the leading zeros, say before doing a hash or other operation which would be affected by them. CAAM should definitely handle it on the "be liberal in what you accept" principle. The kernel should probably remove the leading zeros on the "be conservative in what you do" part of the same principle. > I notice that in my stack trace I have pkcs1pad_verify which > suggests some sort of padding? Yes, RSA has various forms of padding because the information being encrypted is usually much smaller than the encryption unit; PKCS1 is the most common (although its now deprecated in favour of OAEP because of all the padding oracle problems). James
Re: CAAM and IMA/EVM : caam_rsa_enc: DECO: desc idx 7: Protocol Size Error
On Tue, Apr 10, 2018 at 7:43 PM, Martin Townsend
wrote:
> Hi Fabio,
>
> On Tue, Apr 10, 2018 at 7:22 PM, Fabio Estevam wrote:
>> Hi Martin,
>>
>> On Tue, Apr 10, 2018 at 2:06 PM, Martin Townsend
>> wrote:
>>> Hi Fabio,
>>>
>>> On Tue, Apr 10, 2018 at 5:59 PM, Fabio Estevam wrote:
Hi Martin,
On Mon, Apr 9, 2018 at 5:41 AM, Martin Townsend
wrote:
> Hi,
>
> I'm trying to get to the bottom of an issue I'm seeing when enabling
> the CAAM in the kernel with IMA/EVM enabled. I'm using the official
> NXP (imx_4.9.11_1.0.0_ga) vendor Kernel.
Does it work better if you try mainline kernel instead?
>>>
>>> I had a few issues getting mainline working, the board kept resetting,
>>
>> Let's try to fix this reset problem then :-)
>
> My preference would be mainline, no offence to the NXP kernel but it
> would be good to use the LTSI kernel so we get security updates etc :)
> The reset was something to do with USB but that was as far as I got.
>
>>
>>> when I checked there are lots of patches in the NXP kernel not in
>>> mainline. This CAAM problem does occur really early in the boot so
>>> just for an experiment its worth a try.
>>
>> Ok, I just applied this patch that adds CAAM for mx6ull against linux-next:
>>
>> http://code.bulix.org/rjkzt5-317022
>>
>> and I see the following issue with cfg80211 certificate, but I do not
>> get a reset as you reported:
>
> The reset (which is not the reset described above) occurs because I
> have IMA enabled and because it can't load the x509 certificate it
> can't verify init on the filesystem and hence it panics and resets.
>
> The message you are seeing below is the same as I'm seeing. I'm not
> sure if you've seen my later posts but I put some debug statements and
> could see that in my case the signature is 257 bytes and key 270 bytes
> which is at odds with the error message. Reading a post some
> signatures can contain extra information beside the signature so I'm
> wondering if the 257 bytes is a 256 byte signature plus a byte which
> indicates the encryption used to create the signature or something
> like that.
>
A hexdump of the signature reveals a 0x00 at the start
int public_key_verify_signature(const struct public_key *pkey,
const struct public_key_signature *sig)
{
...
print_hex_dump(KERN_ERR, "signature", DUMP_PREFIX_OFFSET, 16, 1,
sig->s, sig->s_size, true);
...
=>
signature: 00 68 82 cc 5d f9 ee fb 1a 77 72 a6 a9 c6 4c cc
.h..]wr...L.
signature0010: d7 f6 2a 17 a5 db bf 5a 2b 8d 39 60 dc a0 93 39
..*Z+.9`...9
signature0020: 45 0f bc a7 e8 7f 6c 06 84 2d f3 c1 94 0a 60 56
E.l..-`V.
...
Using openssl to get the signature in my x509 cert
Signature Algorithm: sha256WithRSAEncryption
68:82:cc:5d:f9:ee:fb:1a:77:72:a6:a9:c6:4c:cc:d7:f6:2a:
17:a5:db:bf:5a:2b:8d:39:60:dc:a0:93:39:45:0f:bc:a7:e8:
7f:6c:06:84:2d:f3:c1:94:0a:60:56:1c:50:78:dc:34:d1:87:
So there's an extra 0x00 and the signature is 257 bytes so I guess
this is upsetting CAAM, just need to work out where it's coming from,
or whether it's valid and CAAM should be handling it. I notice that
in my stack trace I have pkcs1pad_verify which suggests some sort of
padding?
>>
>> [2.999416] caam_jr 2142000.jr1: 4789: DECO: desc idx 7:
>> Protocol Size Error - A protocol has seen an error in size. When
>> running RSA, pdb size N < (size of F) when no formatting is used; or
>> pdb si
>> ze N < (F + 11) when formatting is used.
>> [3.022168] [ cut here ]
>> [3.027247] WARNING: CPU: 0 PID: 1 at
>> crypto/asymmetric_keys/public_key.c:148
>> public_key_verify_signature+0x27c/0x2b0
>> [3.038075] Modules linked in:
>> [3.041226] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
>> 4.16.0-next-20180410-2-gf0ccf31-dirty #223
>> [3.050413] Hardware name: Freescale i.MX6 Ultralite (Device Tree)
>> [3.056643] Backtrace:
>> [3.059173] [] (dump_backtrace) from []
>> (show_stack+0x18/0x1c)
>> [3.066802] r7: r6:6153 r5: r4:c107ae78
>> [3.072523] [] (show_stack) from []
>> (dump_stack+0xb4/0xe8)
>> [3.079810] [] (dump_stack) from []
>> (__warn+0x104/0x130)
>> [3.086922] r9:d604dc94 r8:0094 r7:0009 r6:c0d3aea8
>> r5: r4:
>> [3.094728] [] (__warn) from []
>> (warn_slowpath_null+0x44/0x50)
>> [3.102356] r8:c1008908 r7:d67846c0 r6:c040bbc4 r5:0094 r4:c0d3aea8
>> [3.109120] [] (warn_slowpath_null) from []
>> (public_key_verify_signature+0x27c/0x2b0)
>> [3.118745] r6:4789 r5:d6782f00 r4:d6787f40
>> [3.123428] [] (public_key_verify_signature) from
>> [] (x509_check_for_self_signed+0xc8/0x104)
>> [3.133664] r10:d602f000 r9:c0bcb1d0 r8:02a8 r7:d6787f00
>> r6:d6787f40 r5:
>> [3.141543] r4:d6782d80
>> [3.144140] [] (x509_check_for_self_signed) from
>> [] (x509_cert_parse+0x11c/0x190)
>> [3.153415] r7:c0bcb1d0 r6:d6787f80 r5:d678
Re: CAAM and IMA/EVM : caam_rsa_enc: DECO: desc idx 7: Protocol Size Error
Hi Fabio, On Tue, Apr 10, 2018 at 7:22 PM, Fabio Estevam wrote: > Hi Martin, > > On Tue, Apr 10, 2018 at 2:06 PM, Martin Townsend > wrote: >> Hi Fabio, >> >> On Tue, Apr 10, 2018 at 5:59 PM, Fabio Estevam wrote: >>> Hi Martin, >>> >>> On Mon, Apr 9, 2018 at 5:41 AM, Martin Townsend >>> wrote: Hi, I'm trying to get to the bottom of an issue I'm seeing when enabling the CAAM in the kernel with IMA/EVM enabled. I'm using the official NXP (imx_4.9.11_1.0.0_ga) vendor Kernel. >>> >>> Does it work better if you try mainline kernel instead? >> >> I had a few issues getting mainline working, the board kept resetting, > > Let's try to fix this reset problem then :-) My preference would be mainline, no offence to the NXP kernel but it would be good to use the LTSI kernel so we get security updates etc :) The reset was something to do with USB but that was as far as I got. > >> when I checked there are lots of patches in the NXP kernel not in >> mainline. This CAAM problem does occur really early in the boot so >> just for an experiment its worth a try. > > Ok, I just applied this patch that adds CAAM for mx6ull against linux-next: > > http://code.bulix.org/rjkzt5-317022 > > and I see the following issue with cfg80211 certificate, but I do not > get a reset as you reported: The reset (which is not the reset described above) occurs because I have IMA enabled and because it can't load the x509 certificate it can't verify init on the filesystem and hence it panics and resets. The message you are seeing below is the same as I'm seeing. I'm not sure if you've seen my later posts but I put some debug statements and could see that in my case the signature is 257 bytes and key 270 bytes which is at odds with the error message. Reading a post some signatures can contain extra information beside the signature so I'm wondering if the 257 bytes is a 256 byte signature plus a byte which indicates the encryption used to create the signature or something like that. > > [2.999416] caam_jr 2142000.jr1: 4789: DECO: desc idx 7: > Protocol Size Error - A protocol has seen an error in size. When > running RSA, pdb size N < (size of F) when no formatting is used; or > pdb si > ze N < (F + 11) when formatting is used. > [3.022168] [ cut here ] > [3.027247] WARNING: CPU: 0 PID: 1 at > crypto/asymmetric_keys/public_key.c:148 > public_key_verify_signature+0x27c/0x2b0 > [3.038075] Modules linked in: > [3.041226] CPU: 0 PID: 1 Comm: swapper/0 Not tainted > 4.16.0-next-20180410-2-gf0ccf31-dirty #223 > [3.050413] Hardware name: Freescale i.MX6 Ultralite (Device Tree) > [3.056643] Backtrace: > [3.059173] [] (dump_backtrace) from [] > (show_stack+0x18/0x1c) > [3.066802] r7: r6:6153 r5: r4:c107ae78 > [3.072523] [] (show_stack) from [] > (dump_stack+0xb4/0xe8) > [3.079810] [] (dump_stack) from [] > (__warn+0x104/0x130) > [3.086922] r9:d604dc94 r8:0094 r7:0009 r6:c0d3aea8 > r5: r4: > [3.094728] [] (__warn) from [] > (warn_slowpath_null+0x44/0x50) > [3.102356] r8:c1008908 r7:d67846c0 r6:c040bbc4 r5:0094 r4:c0d3aea8 > [3.109120] [] (warn_slowpath_null) from [] > (public_key_verify_signature+0x27c/0x2b0) > [3.118745] r6:4789 r5:d6782f00 r4:d6787f40 > [3.123428] [] (public_key_verify_signature) from > [] (x509_check_for_self_signed+0xc8/0x104) > [3.133664] r10:d602f000 r9:c0bcb1d0 r8:02a8 r7:d6787f00 > r6:d6787f40 r5: > [3.141543] r4:d6782d80 > [3.144140] [] (x509_check_for_self_signed) from > [] (x509_cert_parse+0x11c/0x190) > [3.153415] r7:c0bcb1d0 r6:d6787f80 r5:d6782d80 r4:d6787f00 > [3.159138] [] (x509_cert_parse) from [] > (x509_key_preparse+0x1c/0x194) > [3.167550] r9:c0bcb1d0 r8:c10235dc r7:d604de30 r6:c1026a84 > r5:d604de30 r4:c1026af0 > [3.175357] [] (x509_key_preparse) from [] > (asymmetric_key_preparse+0x50/0x80) > [3.184376] r9:c0bcb1d0 r8:c10235dc r7:d604de30 r6:c1026a84 > r5:c1008908 r4:c1026af0 > [3.192187] [] (asymmetric_key_preparse) from > [] (key_create_or_update+0x138/0x404) > [3.201638] r7:d6495601 r6:d6495600 r5:c1008908 r4:c1026a8c > [3.207366] [] (key_create_or_update) from [] > (regulatory_init_db+0xf4/0x1e8) > [3.216303] r10:000e r9:1f03 r8:c0d1d144 r7:c17f1e7c > r6:c0bcb478 r5:02a8 > [3.224180] r4:c0bcb1d0 > [3.226780] [] (regulatory_init_db) from [] > (do_one_initcall+0x50/0x1a4) > [3.235278] r10:c0f00630 r9:c0f64858 r8:c107cb00 r7: > r6:c0f5a8d0 r5:c1008908 > [3.243155] r4:e000 > [3.245753] [] (do_one_initcall) from [] > (kernel_init_freeable+0x118/0x1d8) > [3.254512] r9:c0f64858 r8:00f4 r7:c0e1ec98 r6:c0f64854 > r5:c107cb00 r4:c0f78f70 > [3.262324] [] (kernel_init_freeable) from [] > (kernel_init+0x10/0x118) > [3.270650] r10: r9: r8: r7: > r6: r5:c0a665a8 > [
Re: CAAM and IMA/EVM : caam_rsa_enc: DECO: desc idx 7: Protocol Size Error
Hi Martin, On Tue, Apr 10, 2018 at 2:06 PM, Martin Townsend wrote: > Hi Fabio, > > On Tue, Apr 10, 2018 at 5:59 PM, Fabio Estevam wrote: >> Hi Martin, >> >> On Mon, Apr 9, 2018 at 5:41 AM, Martin Townsend >> wrote: >>> Hi, >>> >>> I'm trying to get to the bottom of an issue I'm seeing when enabling >>> the CAAM in the kernel with IMA/EVM enabled. I'm using the official >>> NXP (imx_4.9.11_1.0.0_ga) vendor Kernel. >> >> Does it work better if you try mainline kernel instead? > > I had a few issues getting mainline working, the board kept resetting, Let's try to fix this reset problem then :-) > when I checked there are lots of patches in the NXP kernel not in > mainline. This CAAM problem does occur really early in the boot so > just for an experiment its worth a try. Ok, I just applied this patch that adds CAAM for mx6ull against linux-next: http://code.bulix.org/rjkzt5-317022 and I see the following issue with cfg80211 certificate, but I do not get a reset as you reported: [2.999416] caam_jr 2142000.jr1: 4789: DECO: desc idx 7: Protocol Size Error - A protocol has seen an error in size. When running RSA, pdb size N < (size of F) when no formatting is used; or pdb si ze N < (F + 11) when formatting is used. [3.022168] [ cut here ] [3.027247] WARNING: CPU: 0 PID: 1 at crypto/asymmetric_keys/public_key.c:148 public_key_verify_signature+0x27c/0x2b0 [3.038075] Modules linked in: [3.041226] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.16.0-next-20180410-2-gf0ccf31-dirty #223 [3.050413] Hardware name: Freescale i.MX6 Ultralite (Device Tree) [3.056643] Backtrace: [3.059173] [] (dump_backtrace) from [] (show_stack+0x18/0x1c) [3.066802] r7: r6:6153 r5: r4:c107ae78 [3.072523] [] (show_stack) from [] (dump_stack+0xb4/0xe8) [3.079810] [] (dump_stack) from [] (__warn+0x104/0x130) [3.086922] r9:d604dc94 r8:0094 r7:0009 r6:c0d3aea8 r5: r4: [3.094728] [] (__warn) from [] (warn_slowpath_null+0x44/0x50) [3.102356] r8:c1008908 r7:d67846c0 r6:c040bbc4 r5:0094 r4:c0d3aea8 [3.109120] [] (warn_slowpath_null) from [] (public_key_verify_signature+0x27c/0x2b0) [3.118745] r6:4789 r5:d6782f00 r4:d6787f40 [3.123428] [] (public_key_verify_signature) from [] (x509_check_for_self_signed+0xc8/0x104) [3.133664] r10:d602f000 r9:c0bcb1d0 r8:02a8 r7:d6787f00 r6:d6787f40 r5: [3.141543] r4:d6782d80 [3.144140] [] (x509_check_for_self_signed) from [] (x509_cert_parse+0x11c/0x190) [3.153415] r7:c0bcb1d0 r6:d6787f80 r5:d6782d80 r4:d6787f00 [3.159138] [] (x509_cert_parse) from [] (x509_key_preparse+0x1c/0x194) [3.167550] r9:c0bcb1d0 r8:c10235dc r7:d604de30 r6:c1026a84 r5:d604de30 r4:c1026af0 [3.175357] [] (x509_key_preparse) from [] (asymmetric_key_preparse+0x50/0x80) [3.184376] r9:c0bcb1d0 r8:c10235dc r7:d604de30 r6:c1026a84 r5:c1008908 r4:c1026af0 [3.192187] [] (asymmetric_key_preparse) from [] (key_create_or_update+0x138/0x404) [3.201638] r7:d6495601 r6:d6495600 r5:c1008908 r4:c1026a8c [3.207366] [] (key_create_or_update) from [] (regulatory_init_db+0xf4/0x1e8) [3.216303] r10:000e r9:1f03 r8:c0d1d144 r7:c17f1e7c r6:c0bcb478 r5:02a8 [3.224180] r4:c0bcb1d0 [3.226780] [] (regulatory_init_db) from [] (do_one_initcall+0x50/0x1a4) [3.235278] r10:c0f00630 r9:c0f64858 r8:c107cb00 r7: r6:c0f5a8d0 r5:c1008908 [3.243155] r4:e000 [3.245753] [] (do_one_initcall) from [] (kernel_init_freeable+0x118/0x1d8) [3.254512] r9:c0f64858 r8:00f4 r7:c0e1ec98 r6:c0f64854 r5:c107cb00 r4:c0f78f70 [3.262324] [] (kernel_init_freeable) from [] (kernel_init+0x10/0x118) [3.270650] r10: r9: r8: r7: r6: r5:c0a665a8 [3.278527] r4: [3.281127] [] (kernel_init) from [] (ret_from_fork+0x14/0x20) [3.288749] Exception stack(0xd604dfb0 to 0xd604dff8) [3.293859] dfa0: [3.302098] dfc0: [3.310329] dfe0: 0013 [3.316993] r5:c0a665a8 r4: [3.320825] irq event stamp: 186525 [3.324504] hardirqs last enabled at (186543): [] console_unlock+0x4d4/0x5c8 [3.332584] hardirqs last disabled at (186550): [] console_unlock+0xc8/0x5c8 [3.340664] softirqs last enabled at (186566): [] __do_softirq+0x1f8/0x2a0 [3.348665] softirqs last disabled at (186577): [] irq_exit+0x14c/0x1a8 [3.356307] ---[ end trace abf8fdf803902ee1 ]--- [3.361030] cfg80211: Problem loading in-kernel X.509 certificate (-22) [3.370633] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2 [3.379780] cfg80211: failed to load regulatory.db [3.385260] VSD_3V3: disabling [3.388632] ALSA device list: [
Re: CAAM and IMA/EVM : caam_rsa_enc: DECO: desc idx 7: Protocol Size Error
Hi Fabio, On Tue, Apr 10, 2018 at 5:59 PM, Fabio Estevam wrote: > Hi Martin, > > On Mon, Apr 9, 2018 at 5:41 AM, Martin Townsend > wrote: >> Hi, >> >> I'm trying to get to the bottom of an issue I'm seeing when enabling >> the CAAM in the kernel with IMA/EVM enabled. I'm using the official >> NXP (imx_4.9.11_1.0.0_ga) vendor Kernel. > > Does it work better if you try mainline kernel instead? I had a few issues getting mainline working, the board kept resetting, when I checked there are lots of patches in the NXP kernel not in mainline. This CAAM problem does occur really early in the boot so just for an experiment its worth a try.
Re: CAAM and IMA/EVM : caam_rsa_enc: DECO: desc idx 7: Protocol Size Error
Hi Martin, On Mon, Apr 9, 2018 at 5:41 AM, Martin Townsend wrote: > Hi, > > I'm trying to get to the bottom of an issue I'm seeing when enabling > the CAAM in the kernel with IMA/EVM enabled. I'm using the official > NXP (imx_4.9.11_1.0.0_ga) vendor Kernel. Does it work better if you try mainline kernel instead?
Re: CAAM and IMA/EVM : caam_rsa_enc: DECO: desc idx 7: Protocol Size Error
Hi Mike, On Mon, Apr 9, 2018 at 5:53 PM, Mike Rapoport wrote: > (added CAAM maintainers) > > On Mon, Apr 09, 2018 at 03:10:11PM +0100, Martin Townsend wrote: >> Hi Mimi, >> >> On Mon, Apr 9, 2018 at 1:46 PM, Mimi Zohar wrote: >> > On Mon, 2018-04-09 at 09:41 +0100, Martin Townsend wrote: >> >> Hi, >> >> >> >> I'm trying to get to the bottom of an issue I'm seeing when enabling >> >> the CAAM in the kernel with IMA/EVM enabled. I'm using the official >> >> NXP (imx_4.9.11_1.0.0_ga) vendor Kernel. >> >> > > [ snip ] > >> I think the integrity error message is a side effect of the previous >> error, ie we are getting this error message because the CAAM is >> failing to verify the certificates signature and hence IMA fails to >> load the certificate onto the keyring. If I disable CAAM then >> everything works as expected. What I'm trying to get to the bottom of >> is why CAAM is failing to verify the signature. Further below in the >> email I have determined that the signature is 257 bytes do you think >> this is correct? I've read a post here: >> https://crypto.stackexchange.com/questions/3505/what-is-the-length-of-an-rsa-signature >> >> That says that for PKCS#1 the signature should always be of the size >> of the modulus, then it goes on to say: "In some protocols, there can >> be some wrapping around the signature, e.g. to indicate which >> algorithm was used," I'm wondering if that's what I'm seeing, an >> extra byte in the signature that is the type of algorithm used but >> this extra byte is also passed to the CAAM and causes it to fail as >> then the signature is now larger than the modulus. But I don't know >> what I can do about this, I'm not even sure what protocol is being >> used to generate this extra byte, any suggestions on how to find this >> out would be appreciated. > > I don't really understand crypto and I maybe talking complete nonsense, but > judging by diffstat between the imx_4.9.11_1.0.0_ga and mainline, the CAAM > driver had a lot of additions since then :) > > The caam_rsa_dec function gained form 2 and form of 3 RSA decoding. > That might explain your issue... > Thanks very interesting, definitely worth investigating, hopefully they will backport fairly easily. I'm not seeing any caam_rsa_dec but I do see caam_rsa_enc, is this expected when verifying signatures? public_key_verify_signature -> pkcs1pad_verify -> caam_rsa_enc >> > >> > >> >> I put a dump_stack in the error handling routine in CAAM and in the >> >> caam_jr_enqueue to get (I removed some of the caam_jr_enqueue >> >> dump_stacks during initialisation to highlight the one of interest) > > Does any of the other caam_jr_enqueue stacks include > load_system_certificate_list() call? Not that I've seen, the only stack trace I've seen stem from integrity_load_x509; the IMA x509 certificate is the first thing that gets processed by CAAM. > If you have a x509 certificate built into the kernel I presume it will also > pass through caam_rsa_dec. > > You can also try using the built-in certificate as IMA x509 certificate and > see > if it changes anything. I'm compiling the certificate into the kernel as it's required so early in the boot for IMA. > >> >> caam 214.caam: ERA source: CCBVID. >> >> caam 214.caam: Entropy delay = 3200 >> >> caam 214.caam: Instantiated RNG4 SH0 >> >> caam 214.caam: Instantiated RNG4 SH1 >> >> caam 214.caam: device ID = 0x0a160300 (Era 8) >> >> caam 214.caam: job rings = 3, qi = 0 >> >> caam algorithms registered in /proc/crypto >> >> caam_jr_enqueue >> >> CPU: 0 PID: 1 Comm: swapper Not tainted 4.9.11-1.0.0+gc27010d #4 >> >> Hardware name: Freescale i.MX6 UltraLite (Device Tree) >> >> caam_jr_enqueue >> >> CPU: 0 PID: 1 Comm: swapper Not tainted 4.9.11-1.0.0+gc27010d #4 >> >> Hardware name: Freescale i.MX6 UltraLite (Device Tree) >> >> caam_jr 2141000.jr0: registering rng-caam >> >> caam 214.caam: caam pkc algorithms registered in /proc/crypto >> >> caam_jr_enqueue >> >> CPU: 0 PID: 1 Comm: swapper Not tainted 4.9.11-1.0.0+gc27010d #4 >> >> Hardware name: Freescale i.MX6 UltraLite (Device Tree) >> >> caam_rsa_set_pub_key >> >> caam_rsa_max_size >> >> caam_rsa_enc >> >> caam_jr_enqueue >> >> CPU: 0 PID: 1 Comm: swapper Not tainted 4.9.11-1.0.0+gc27010d #4 >> >> Hardware name: Freescale i.MX6 UltraLite (Device Tree) >> >> [<8010dd8c>] (unwind_backtrace) from [<8010b8cc>] (show_stack+0x10/0x14) >> >> [<8010b8cc>] (show_stack) from [<80608f74>] (caam_jr_enqueue+0x3c/0x2bc) >> >> [<80608f74>] (caam_jr_enqueue) from [<8061fb84>] >> >> (caam_rsa_enc+0x210/0x3ac) >> >> [<8061fb84>] (caam_rsa_enc) from [<803ed910>] (pkcs1pad_verify+0xa8/0xe4) >> >> [<803ed910>] (pkcs1pad_verify) from [<804134e4>] >> >> (public_key_verify_signature+0x17c/0x248) >> >> [<804134e4>] (public_key_verify_signature) from [<804132a0>] >> >> (restrict_link_by_signature+0xa8/0xd4) >> >> [<804132a0>] (restrict_link_by_signature) from [<803cadd4>] >> >> (key_create_or_update+0x12c/0x370
Re: CAAM and IMA/EVM : caam_rsa_enc: DECO: desc idx 7: Protocol Size Error
(added CAAM maintainers) On Mon, Apr 09, 2018 at 03:10:11PM +0100, Martin Townsend wrote: > Hi Mimi, > > On Mon, Apr 9, 2018 at 1:46 PM, Mimi Zohar wrote: > > On Mon, 2018-04-09 at 09:41 +0100, Martin Townsend wrote: > >> Hi, > >> > >> I'm trying to get to the bottom of an issue I'm seeing when enabling > >> the CAAM in the kernel with IMA/EVM enabled. I'm using the official > >> NXP (imx_4.9.11_1.0.0_ga) vendor Kernel. > >> [ snip ] > I think the integrity error message is a side effect of the previous > error, ie we are getting this error message because the CAAM is > failing to verify the certificates signature and hence IMA fails to > load the certificate onto the keyring. If I disable CAAM then > everything works as expected. What I'm trying to get to the bottom of > is why CAAM is failing to verify the signature. Further below in the > email I have determined that the signature is 257 bytes do you think > this is correct? I've read a post here: > https://crypto.stackexchange.com/questions/3505/what-is-the-length-of-an-rsa-signature > > That says that for PKCS#1 the signature should always be of the size > of the modulus, then it goes on to say: "In some protocols, there can > be some wrapping around the signature, e.g. to indicate which > algorithm was used," I'm wondering if that's what I'm seeing, an > extra byte in the signature that is the type of algorithm used but > this extra byte is also passed to the CAAM and causes it to fail as > then the signature is now larger than the modulus. But I don't know > what I can do about this, I'm not even sure what protocol is being > used to generate this extra byte, any suggestions on how to find this > out would be appreciated. I don't really understand crypto and I maybe talking complete nonsense, but judging by diffstat between the imx_4.9.11_1.0.0_ga and mainline, the CAAM driver had a lot of additions since then :) The caam_rsa_dec function gained form 2 and form of 3 RSA decoding. That might explain your issue... > > > > > >> I put a dump_stack in the error handling routine in CAAM and in the > >> caam_jr_enqueue to get (I removed some of the caam_jr_enqueue > >> dump_stacks during initialisation to highlight the one of interest) Does any of the other caam_jr_enqueue stacks include load_system_certificate_list() call? If you have a x509 certificate built into the kernel I presume it will also pass through caam_rsa_dec. You can also try using the built-in certificate as IMA x509 certificate and see if it changes anything. > >> caam 214.caam: ERA source: CCBVID. > >> caam 214.caam: Entropy delay = 3200 > >> caam 214.caam: Instantiated RNG4 SH0 > >> caam 214.caam: Instantiated RNG4 SH1 > >> caam 214.caam: device ID = 0x0a160300 (Era 8) > >> caam 214.caam: job rings = 3, qi = 0 > >> caam algorithms registered in /proc/crypto > >> caam_jr_enqueue > >> CPU: 0 PID: 1 Comm: swapper Not tainted 4.9.11-1.0.0+gc27010d #4 > >> Hardware name: Freescale i.MX6 UltraLite (Device Tree) > >> caam_jr_enqueue > >> CPU: 0 PID: 1 Comm: swapper Not tainted 4.9.11-1.0.0+gc27010d #4 > >> Hardware name: Freescale i.MX6 UltraLite (Device Tree) > >> caam_jr 2141000.jr0: registering rng-caam > >> caam 214.caam: caam pkc algorithms registered in /proc/crypto > >> caam_jr_enqueue > >> CPU: 0 PID: 1 Comm: swapper Not tainted 4.9.11-1.0.0+gc27010d #4 > >> Hardware name: Freescale i.MX6 UltraLite (Device Tree) > >> caam_rsa_set_pub_key > >> caam_rsa_max_size > >> caam_rsa_enc > >> caam_jr_enqueue > >> CPU: 0 PID: 1 Comm: swapper Not tainted 4.9.11-1.0.0+gc27010d #4 > >> Hardware name: Freescale i.MX6 UltraLite (Device Tree) > >> [<8010dd8c>] (unwind_backtrace) from [<8010b8cc>] (show_stack+0x10/0x14) > >> [<8010b8cc>] (show_stack) from [<80608f74>] (caam_jr_enqueue+0x3c/0x2bc) > >> [<80608f74>] (caam_jr_enqueue) from [<8061fb84>] (caam_rsa_enc+0x210/0x3ac) > >> [<8061fb84>] (caam_rsa_enc) from [<803ed910>] (pkcs1pad_verify+0xa8/0xe4) > >> [<803ed910>] (pkcs1pad_verify) from [<804134e4>] > >> (public_key_verify_signature+0x17c/0x248) > >> [<804134e4>] (public_key_verify_signature) from [<804132a0>] > >> (restrict_link_by_signature+0xa8/0xd4) > >> [<804132a0>] (restrict_link_by_signature) from [<803cadd4>] > >> (key_create_or_update+0x12c/0x370) > >> [<803cadd4>] (key_create_or_update) from [<80c253a0>] > >> (integrity_load_x509+0x70/0xc4) > >> [<80c253a0>] (integrity_load_x509) from [<80c256bc>] > >> (ima_load_x509+0x28/0x3c) > >> [<80c256bc>] (ima_load_x509) from [<80c2510c>] > >> (integrity_load_keys+0x8/0x10) > >> [<80c2510c>] (integrity_load_keys) from [<80c00de0>] > >> (kernel_init_freeable+0x1bc/0x1cc) > >> [<80c00de0>] (kernel_init_freeable) from [<80844ccc>] > >> (kernel_init+0x8/0x114) > >> [<80844ccc>] (kernel_init) from [<801078d8>] (ret_from_fork+0x14/0x3c) > >> CPU: 0 PID: 112 Comm: irq/214-2142000 Not tainted 4.9.11-1.0.0+gc27010d #4 > >> Hardware name: Freescale i.MX6 UltraLite (Device Tree) > >> [<8010dd8c>] (u
Re: CAAM and IMA/EVM : caam_rsa_enc: DECO: desc idx 7: Protocol Size Error
On Mon, 2018-04-09 at 15:10 +0100, Martin Townsend wrote: > Hi Mimi, > > On Mon, Apr 9, 2018 at 1:46 PM, Mimi Zohar wrote: > > On Mon, 2018-04-09 at 09:41 +0100, Martin Townsend wrote: > >> Hi, > >> > >> I'm trying to get to the bottom of an issue I'm seeing when enabling > >> the CAAM in the kernel with IMA/EVM enabled. I'm using the official > >> NXP (imx_4.9.11_1.0.0_ga) vendor Kernel. > >> > >> Here's the error message I'm getting. > >> > >> caam_jr 2142000.jr1: 4789: DECO: desc idx 7: Protocol Size Error - > >> A protocol has seen an error in size. When running RSA, pdb size N < > >> (size of F) when no formatting is used; or pdb size N < (F + 11) when > >> formatting is used. > >> integrity: Problem loading X.509 certificate (-129): /etc/keys/ima-x509.der > > > > This error message indicates that the kernel is trying to load a key > > onto the IMA keyring, but any key added to the trusted IMA keyring > > (.ima) must be signed by a key on the builtin (or secondary) keyring. > > > > Please verify that the public key used to sign the ima-x509.der is on > > the builtin keyring (eg. "keyctl show %keyring:.builtin_trusted_keys) > > or the secondary keyring. Depending on how the kernel was configured, > > loading the public CA onto the builtin (or secondary) keyring might be > > possible. > > > > Some distros are carrying patches which load the UEFI keys onto the > > secondary keyring. The other (preferred) method would be to insert > > the CA certificate into the kernel and resign the kernel. This > > requires reserving memory for the key when the kernel is built. > > > > CONFIG_SYSTEM_EXTRA_CERTIFICATE=y > > CONFIG_SYSTEM_EXTRA_CERTIFICATE_SIZE=4096 > > > > Mimi > > I think the integrity error message is a side effect of the previous > error, ie we are getting this error message because the CAAM is > failing to verify the certificates signature and hence IMA fails to > load the certificate onto the keyring. If I disable CAAM then > everything works as expected. Thanks! > What I'm trying to get to the bottom of > is why CAAM is failing to verify the signature. Further below in the > email I have determined that the signature is 257 bytes do you think > this is correct? Sorry, I'm not going to be of much help here. Remember everything that CAAM uses (eg. kernel crypto modules) must be builtin to the kernel until a key is loaded onto to the IMA keyring. Perhaps enabling pr_devel/pr_debug in crypto/asymmetric_keys/ might provide some additional information. Mimi > I've read a post here: > https://crypto.stackexchange.com/questions/3505/what-is-the-length-of-an-rsa-signature > That says that for PKCS#1 the signature should always be of the size > of the modulus, then it goes on to say: "In some protocols, there can > be some wrapping around the signature, e.g. to indicate which > algorithm was used," I'm wondering if that's what I'm seeing, an > extra byte in the signature that is the type of algorithm used but > this extra byte is also passed to the CAAM and causes it to fail as > then the signature is now larger than the modulus. But I don't know > what I can do about this, I'm not even sure what protocol is being > used to generate this extra byte, any suggestions on how to find this > out would be appreciated. > > > > > > >> I put a dump_stack in the error handling routine in CAAM and in the > >> caam_jr_enqueue to get (I removed some of the caam_jr_enqueue > >> dump_stacks during initialisation to highlight the one of interest) > >> > >> caam 214.caam: ERA source: CCBVID. > >> caam 214.caam: Entropy delay = 3200 > >> caam 214.caam: Instantiated RNG4 SH0 > >> caam 214.caam: Instantiated RNG4 SH1 > >> caam 214.caam: device ID = 0x0a160300 (Era 8) > >> caam 214.caam: job rings = 3, qi = 0 > >> caam algorithms registered in /proc/crypto > >> caam_jr_enqueue > >> CPU: 0 PID: 1 Comm: swapper Not tainted 4.9.11-1.0.0+gc27010d #4 > >> Hardware name: Freescale i.MX6 UltraLite (Device Tree) > >> caam_jr_enqueue > >> CPU: 0 PID: 1 Comm: swapper Not tainted 4.9.11-1.0.0+gc27010d #4 > >> Hardware name: Freescale i.MX6 UltraLite (Device Tree) > >> caam_jr 2141000.jr0: registering rng-caam > >> caam 214.caam: caam pkc algorithms registered in /proc/crypto > >> caam_jr_enqueue > >> CPU: 0 PID: 1 Comm: swapper Not tainted 4.9.11-1.0.0+gc27010d #4 > >> Hardware name: Freescale i.MX6 UltraLite (Device Tree) > >> caam_rsa_set_pub_key > >> caam_rsa_max_size > >> caam_rsa_enc > >> caam_jr_enqueue > >> CPU: 0 PID: 1 Comm: swapper Not tainted 4.9.11-1.0.0+gc27010d #4 > >> Hardware name: Freescale i.MX6 UltraLite (Device Tree) > >> [<8010dd8c>] (unwind_backtrace) from [<8010b8cc>] (show_stack+0x10/0x14) > >> [<8010b8cc>] (show_stack) from [<80608f74>] (caam_jr_enqueue+0x3c/0x2bc) > >> [<80608f74>] (caam_jr_enqueue) from [<8061fb84>] (caam_rsa_enc+0x210/0x3ac) > >> [<8061fb84>] (caam_rsa_enc) from [<803ed910>] (pkcs1pad_verify+0xa8/0xe4) > >> [<803ed910>] (pkcs1pad_verif
Re: CAAM and IMA/EVM : caam_rsa_enc: DECO: desc idx 7: Protocol Size Error
Hi Mimi, On Mon, Apr 9, 2018 at 1:46 PM, Mimi Zohar wrote: > On Mon, 2018-04-09 at 09:41 +0100, Martin Townsend wrote: >> Hi, >> >> I'm trying to get to the bottom of an issue I'm seeing when enabling >> the CAAM in the kernel with IMA/EVM enabled. I'm using the official >> NXP (imx_4.9.11_1.0.0_ga) vendor Kernel. >> >> Here's the error message I'm getting. >> >> caam_jr 2142000.jr1: 4789: DECO: desc idx 7: Protocol Size Error - >> A protocol has seen an error in size. When running RSA, pdb size N < >> (size of F) when no formatting is used; or pdb size N < (F + 11) when >> formatting is used. >> integrity: Problem loading X.509 certificate (-129): /etc/keys/ima-x509.der > > This error message indicates that the kernel is trying to load a key > onto the IMA keyring, but any key added to the trusted IMA keyring > (.ima) must be signed by a key on the builtin (or secondary) keyring. > > Please verify that the public key used to sign the ima-x509.der is on > the builtin keyring (eg. "keyctl show %keyring:.builtin_trusted_keys) > or the secondary keyring. Depending on how the kernel was configured, > loading the public CA onto the builtin (or secondary) keyring might be > possible. > > Some distros are carrying patches which load the UEFI keys onto the > secondary keyring. The other (preferred) method would be to insert > the CA certificate into the kernel and resign the kernel. This > requires reserving memory for the key when the kernel is built. > > CONFIG_SYSTEM_EXTRA_CERTIFICATE=y > CONFIG_SYSTEM_EXTRA_CERTIFICATE_SIZE=4096 > > Mimi I think the integrity error message is a side effect of the previous error, ie we are getting this error message because the CAAM is failing to verify the certificates signature and hence IMA fails to load the certificate onto the keyring. If I disable CAAM then everything works as expected. What I'm trying to get to the bottom of is why CAAM is failing to verify the signature. Further below in the email I have determined that the signature is 257 bytes do you think this is correct? I've read a post here: https://crypto.stackexchange.com/questions/3505/what-is-the-length-of-an-rsa-signature That says that for PKCS#1 the signature should always be of the size of the modulus, then it goes on to say: "In some protocols, there can be some wrapping around the signature, e.g. to indicate which algorithm was used," I'm wondering if that's what I'm seeing, an extra byte in the signature that is the type of algorithm used but this extra byte is also passed to the CAAM and causes it to fail as then the signature is now larger than the modulus. But I don't know what I can do about this, I'm not even sure what protocol is being used to generate this extra byte, any suggestions on how to find this out would be appreciated. > > >> I put a dump_stack in the error handling routine in CAAM and in the >> caam_jr_enqueue to get (I removed some of the caam_jr_enqueue >> dump_stacks during initialisation to highlight the one of interest) >> >> caam 214.caam: ERA source: CCBVID. >> caam 214.caam: Entropy delay = 3200 >> caam 214.caam: Instantiated RNG4 SH0 >> caam 214.caam: Instantiated RNG4 SH1 >> caam 214.caam: device ID = 0x0a160300 (Era 8) >> caam 214.caam: job rings = 3, qi = 0 >> caam algorithms registered in /proc/crypto >> caam_jr_enqueue >> CPU: 0 PID: 1 Comm: swapper Not tainted 4.9.11-1.0.0+gc27010d #4 >> Hardware name: Freescale i.MX6 UltraLite (Device Tree) >> caam_jr_enqueue >> CPU: 0 PID: 1 Comm: swapper Not tainted 4.9.11-1.0.0+gc27010d #4 >> Hardware name: Freescale i.MX6 UltraLite (Device Tree) >> caam_jr 2141000.jr0: registering rng-caam >> caam 214.caam: caam pkc algorithms registered in /proc/crypto >> caam_jr_enqueue >> CPU: 0 PID: 1 Comm: swapper Not tainted 4.9.11-1.0.0+gc27010d #4 >> Hardware name: Freescale i.MX6 UltraLite (Device Tree) >> caam_rsa_set_pub_key >> caam_rsa_max_size >> caam_rsa_enc >> caam_jr_enqueue >> CPU: 0 PID: 1 Comm: swapper Not tainted 4.9.11-1.0.0+gc27010d #4 >> Hardware name: Freescale i.MX6 UltraLite (Device Tree) >> [<8010dd8c>] (unwind_backtrace) from [<8010b8cc>] (show_stack+0x10/0x14) >> [<8010b8cc>] (show_stack) from [<80608f74>] (caam_jr_enqueue+0x3c/0x2bc) >> [<80608f74>] (caam_jr_enqueue) from [<8061fb84>] (caam_rsa_enc+0x210/0x3ac) >> [<8061fb84>] (caam_rsa_enc) from [<803ed910>] (pkcs1pad_verify+0xa8/0xe4) >> [<803ed910>] (pkcs1pad_verify) from [<804134e4>] >> (public_key_verify_signature+0x17c/0x248) >> [<804134e4>] (public_key_verify_signature) from [<804132a0>] >> (restrict_link_by_signature+0xa8/0xd4) >> [<804132a0>] (restrict_link_by_signature) from [<803cadd4>] >> (key_create_or_update+0x12c/0x370) >> [<803cadd4>] (key_create_or_update) from [<80c253a0>] >> (integrity_load_x509+0x70/0xc4) >> [<80c253a0>] (integrity_load_x509) from [<80c256bc>] >> (ima_load_x509+0x28/0x3c) >> [<80c256bc>] (ima_load_x509) from [<80c2510c>] (integrity_load_keys+0x8/0x10) >> [<80c2510c>] (integrity
Re: CAAM and IMA/EVM : caam_rsa_enc: DECO: desc idx 7: Protocol Size Error
On Mon, 2018-04-09 at 09:41 +0100, Martin Townsend wrote: > Hi, > > I'm trying to get to the bottom of an issue I'm seeing when enabling > the CAAM in the kernel with IMA/EVM enabled. I'm using the official > NXP (imx_4.9.11_1.0.0_ga) vendor Kernel. > > Here's the error message I'm getting. > > caam_jr 2142000.jr1: 4789: DECO: desc idx 7: Protocol Size Error - > A protocol has seen an error in size. When running RSA, pdb size N < > (size of F) when no formatting is used; or pdb size N < (F + 11) when > formatting is used. > integrity: Problem loading X.509 certificate (-129): /etc/keys/ima-x509.der This error message indicates that the kernel is trying to load a key onto the IMA keyring, but any key added to the trusted IMA keyring (.ima) must be signed by a key on the builtin (or secondary) keyring. Please verify that the public key used to sign the ima-x509.der is on the builtin keyring (eg. "keyctl show %keyring:.builtin_trusted_keys) or the secondary keyring. Depending on how the kernel was configured, loading the public CA onto the builtin (or secondary) keyring might be possible. Some distros are carrying patches which load the UEFI keys onto the secondary keyring. The other (preferred) method would be to insert the CA certificate into the kernel and resign the kernel. This requires reserving memory for the key when the kernel is built. CONFIG_SYSTEM_EXTRA_CERTIFICATE=y CONFIG_SYSTEM_EXTRA_CERTIFICATE_SIZE=4096 Mimi > I put a dump_stack in the error handling routine in CAAM and in the > caam_jr_enqueue to get (I removed some of the caam_jr_enqueue > dump_stacks during initialisation to highlight the one of interest) > > caam 214.caam: ERA source: CCBVID. > caam 214.caam: Entropy delay = 3200 > caam 214.caam: Instantiated RNG4 SH0 > caam 214.caam: Instantiated RNG4 SH1 > caam 214.caam: device ID = 0x0a160300 (Era 8) > caam 214.caam: job rings = 3, qi = 0 > caam algorithms registered in /proc/crypto > caam_jr_enqueue > CPU: 0 PID: 1 Comm: swapper Not tainted 4.9.11-1.0.0+gc27010d #4 > Hardware name: Freescale i.MX6 UltraLite (Device Tree) > caam_jr_enqueue > CPU: 0 PID: 1 Comm: swapper Not tainted 4.9.11-1.0.0+gc27010d #4 > Hardware name: Freescale i.MX6 UltraLite (Device Tree) > caam_jr 2141000.jr0: registering rng-caam > caam 214.caam: caam pkc algorithms registered in /proc/crypto > caam_jr_enqueue > CPU: 0 PID: 1 Comm: swapper Not tainted 4.9.11-1.0.0+gc27010d #4 > Hardware name: Freescale i.MX6 UltraLite (Device Tree) > caam_rsa_set_pub_key > caam_rsa_max_size > caam_rsa_enc > caam_jr_enqueue > CPU: 0 PID: 1 Comm: swapper Not tainted 4.9.11-1.0.0+gc27010d #4 > Hardware name: Freescale i.MX6 UltraLite (Device Tree) > [<8010dd8c>] (unwind_backtrace) from [<8010b8cc>] (show_stack+0x10/0x14) > [<8010b8cc>] (show_stack) from [<80608f74>] (caam_jr_enqueue+0x3c/0x2bc) > [<80608f74>] (caam_jr_enqueue) from [<8061fb84>] (caam_rsa_enc+0x210/0x3ac) > [<8061fb84>] (caam_rsa_enc) from [<803ed910>] (pkcs1pad_verify+0xa8/0xe4) > [<803ed910>] (pkcs1pad_verify) from [<804134e4>] > (public_key_verify_signature+0x17c/0x248) > [<804134e4>] (public_key_verify_signature) from [<804132a0>] > (restrict_link_by_signature+0xa8/0xd4) > [<804132a0>] (restrict_link_by_signature) from [<803cadd4>] > (key_create_or_update+0x12c/0x370) > [<803cadd4>] (key_create_or_update) from [<80c253a0>] > (integrity_load_x509+0x70/0xc4) > [<80c253a0>] (integrity_load_x509) from [<80c256bc>] (ima_load_x509+0x28/0x3c) > [<80c256bc>] (ima_load_x509) from [<80c2510c>] (integrity_load_keys+0x8/0x10) > [<80c2510c>] (integrity_load_keys) from [<80c00de0>] > (kernel_init_freeable+0x1bc/0x1cc) > [<80c00de0>] (kernel_init_freeable) from [<80844ccc>] (kernel_init+0x8/0x114) > [<80844ccc>] (kernel_init) from [<801078d8>] (ret_from_fork+0x14/0x3c) > CPU: 0 PID: 112 Comm: irq/214-2142000 Not tainted 4.9.11-1.0.0+gc27010d #4 > Hardware name: Freescale i.MX6 UltraLite (Device Tree) > [<8010dd8c>] (unwind_backtrace) from [<8010b8cc>] (show_stack+0x10/0x14) > [<8010b8cc>] (show_stack) from [<8060a0e8>] (report_deco_status+0x30/0xf8) > [<8060a0e8>] (report_deco_status) from [<8061f3c8>] (rsa_pub_done+0x20/0x60) > [<8061f3c8>] (rsa_pub_done) from [<80608d94>] (caam_jr_threadirq+0x1dc/0x29c) > [<80608d94>] (caam_jr_threadirq) from [<80165dcc>] (irq_thread_fn+0x1c/0x54) > [<80165dcc>] (irq_thread_fn) from [<80166024>] (irq_thread+0x114/0x1d4) > [<80166024>] (irq_thread) from [<801415b4>] (kthread+0xe4/0xec) > [<801415b4>] (kthread) from [<801078d8>] (ret_from_fork+0x14/0x3c) > caam_jr 2142000.jr1: 4789: DECO: desc idx 7: Protocol Size Error - > A protocol has seen an error in size. When running RSA, pdb size N < > (size of F) when no formatting is used; or pdb size N < (F + 11) when > formatting is used. > integrity: Problem loading X.509 certificate (-129): /etc/keys/ima-x509.der > [<8010dd8c>] (unwind_backtrace) from [<8010b8cc>] (show_stack+0x10/0x14) > [<8010b8cc>] (show_stack) from [<8060a0d0>] (repo
CAAM and IMA/EVM : caam_rsa_enc: DECO: desc idx 7: Protocol Size Error
Hi, I'm trying to get to the bottom of an issue I'm seeing when enabling the CAAM in the kernel with IMA/EVM enabled. I'm using the official NXP (imx_4.9.11_1.0.0_ga) vendor Kernel. Here's the error message I'm getting. caam_jr 2142000.jr1: 4789: DECO: desc idx 7: Protocol Size Error - A protocol has seen an error in size. When running RSA, pdb size N < (size of F) when no formatting is used; or pdb size N < (F + 11) when formatting is used. integrity: Problem loading X.509 certificate (-129): /etc/keys/ima-x509.der I put a dump_stack in the error handling routine in CAAM and in the caam_jr_enqueue to get (I removed some of the caam_jr_enqueue dump_stacks during initialisation to highlight the one of interest) caam 214.caam: ERA source: CCBVID. caam 214.caam: Entropy delay = 3200 caam 214.caam: Instantiated RNG4 SH0 caam 214.caam: Instantiated RNG4 SH1 caam 214.caam: device ID = 0x0a160300 (Era 8) caam 214.caam: job rings = 3, qi = 0 caam algorithms registered in /proc/crypto caam_jr_enqueue CPU: 0 PID: 1 Comm: swapper Not tainted 4.9.11-1.0.0+gc27010d #4 Hardware name: Freescale i.MX6 UltraLite (Device Tree) caam_jr_enqueue CPU: 0 PID: 1 Comm: swapper Not tainted 4.9.11-1.0.0+gc27010d #4 Hardware name: Freescale i.MX6 UltraLite (Device Tree) caam_jr 2141000.jr0: registering rng-caam caam 214.caam: caam pkc algorithms registered in /proc/crypto caam_jr_enqueue CPU: 0 PID: 1 Comm: swapper Not tainted 4.9.11-1.0.0+gc27010d #4 Hardware name: Freescale i.MX6 UltraLite (Device Tree) caam_rsa_set_pub_key caam_rsa_max_size caam_rsa_enc caam_jr_enqueue CPU: 0 PID: 1 Comm: swapper Not tainted 4.9.11-1.0.0+gc27010d #4 Hardware name: Freescale i.MX6 UltraLite (Device Tree) [<8010dd8c>] (unwind_backtrace) from [<8010b8cc>] (show_stack+0x10/0x14) [<8010b8cc>] (show_stack) from [<80608f74>] (caam_jr_enqueue+0x3c/0x2bc) [<80608f74>] (caam_jr_enqueue) from [<8061fb84>] (caam_rsa_enc+0x210/0x3ac) [<8061fb84>] (caam_rsa_enc) from [<803ed910>] (pkcs1pad_verify+0xa8/0xe4) [<803ed910>] (pkcs1pad_verify) from [<804134e4>] (public_key_verify_signature+0x17c/0x248) [<804134e4>] (public_key_verify_signature) from [<804132a0>] (restrict_link_by_signature+0xa8/0xd4) [<804132a0>] (restrict_link_by_signature) from [<803cadd4>] (key_create_or_update+0x12c/0x370) [<803cadd4>] (key_create_or_update) from [<80c253a0>] (integrity_load_x509+0x70/0xc4) [<80c253a0>] (integrity_load_x509) from [<80c256bc>] (ima_load_x509+0x28/0x3c) [<80c256bc>] (ima_load_x509) from [<80c2510c>] (integrity_load_keys+0x8/0x10) [<80c2510c>] (integrity_load_keys) from [<80c00de0>] (kernel_init_freeable+0x1bc/0x1cc) [<80c00de0>] (kernel_init_freeable) from [<80844ccc>] (kernel_init+0x8/0x114) [<80844ccc>] (kernel_init) from [<801078d8>] (ret_from_fork+0x14/0x3c) CPU: 0 PID: 112 Comm: irq/214-2142000 Not tainted 4.9.11-1.0.0+gc27010d #4 Hardware name: Freescale i.MX6 UltraLite (Device Tree) [<8010dd8c>] (unwind_backtrace) from [<8010b8cc>] (show_stack+0x10/0x14) [<8010b8cc>] (show_stack) from [<8060a0e8>] (report_deco_status+0x30/0xf8) [<8060a0e8>] (report_deco_status) from [<8061f3c8>] (rsa_pub_done+0x20/0x60) [<8061f3c8>] (rsa_pub_done) from [<80608d94>] (caam_jr_threadirq+0x1dc/0x29c) [<80608d94>] (caam_jr_threadirq) from [<80165dcc>] (irq_thread_fn+0x1c/0x54) [<80165dcc>] (irq_thread_fn) from [<80166024>] (irq_thread+0x114/0x1d4) [<80166024>] (irq_thread) from [<801415b4>] (kthread+0xe4/0xec) [<801415b4>] (kthread) from [<801078d8>] (ret_from_fork+0x14/0x3c) caam_jr 2142000.jr1: 4789: DECO: desc idx 7: Protocol Size Error - A protocol has seen an error in size. When running RSA, pdb size N < (size of F) when no formatting is used; or pdb size N < (F + 11) when formatting is used. integrity: Problem loading X.509 certificate (-129): /etc/keys/ima-x509.der [<8010dd8c>] (unwind_backtrace) from [<8010b8cc>] (show_stack+0x10/0x14) [<8010b8cc>] (show_stack) from [<8060a0d0>] (report_deco_status+0x30/0xf8) [<8060a0d0>] (report_deco_status) from [<8061db94>] (rsa_pub_done+0x20/0x60) [<8061db94>] (rsa_pub_done) from [<80608d94>] (caam_jr_threadirq+0x1dc/0x29c) [<80608d94>] (caam_jr_threadirq) from [<80165dcc>] (irq_thread_fn+0x1c/0x54) [<80165dcc>] (irq_thread_fn) from [<80166024>] (irq_thread+0x114/0x1d4) [<80166024>] (irq_thread) from [<801415b4>] (kthread+0xe4/0xec) [<801415b4>] (kthread) from [<801078d8>] (ret_from_fork+0x14/0x3c) So it's failing to verify the signature on my x509 certificate because pdb size M < (size of F) ... On the NXP mailing lists there is someone with a similar issue and the response was “The error appears to be saying that the public RSA modulus is shorter than the signature being verified. RSA uses modular arithmetic, and all valid values are smaller than the public RSA modulus. However, the signature (F in the error message below), is too large. The customer should try to determine why their public RSA Modulus (N) is shorter than the signature (F).” I have to admit I'm not really sure
