Re: CAAM and IMA/EVM : caam_rsa_enc: DECO: desc idx 7: Protocol Size Error

[Fabio Estevam]

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: [PATCH v2 1/2] crypto: caam - staticize caam_get_era()

[Fabio Estevam]

On Tue, Apr 10, 2018 at 10:54 PM, Fabio Estevam  wrote:
> From: Fabio Estevam 
>
> caam_get_era() is only used locally, so do not export this function
> and make it static instead.
>
> Signed-off-by: Fabio Estevam 
> ---
> Changes since v1:
> - None. I previously asked to put the linux-crypto list on Cc

Ops, I meant "None. I previously forgot to put the linux-crypto list on Cc"

[PATCH v2 1/2] crypto: caam - staticize caam_get_era()

[Fabio Estevam]

From: Fabio Estevam 

caam_get_era() is only used locally, so do not export this function
and make it static instead.

Signed-off-by: Fabio Estevam 
---
Changes since v1:
- None. I previously asked to put the linux-crypto list on Cc

 drivers/crypto/caam/ctrl.c | 3 +--
 drivers/crypto/caam/ctrl.h | 2 --
 2 files changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/crypto/caam/ctrl.c b/drivers/crypto/caam/ctrl.c
index e4cc636..bee690a 100644
--- a/drivers/crypto/caam/ctrl.c
+++ b/drivers/crypto/caam/ctrl.c
@@ -400,7 +400,7 @@ static void kick_trng(struct platform_device *pdev, int 
ent_delay)
  * caam_get_era() - Return the ERA of the SEC on SoC, based
  * on "sec-era" propery in the DTS. This property is updated by u-boot.
  **/
-int caam_get_era(void)
+static int caam_get_era(void)
 {
struct device_node *caam_node;
int ret;
@@ -412,7 +412,6 @@ int caam_get_era(void)
 
return ret ? -ENOTSUPP : prop;
 }
-EXPORT_SYMBOL(caam_get_era);
 
 static const struct of_device_id caam_match[] = {
{
diff --git a/drivers/crypto/caam/ctrl.h b/drivers/crypto/caam/ctrl.h
index be693a2..f3ecd67 100644
--- a/drivers/crypto/caam/ctrl.h
+++ b/drivers/crypto/caam/ctrl.h
@@ -9,8 +9,6 @@
 #define CTRL_H
 
 /* Prototypes for backend-level services exposed to APIs */
-int caam_get_era(void);
-
 extern bool caam_dpaa2;
 
 #endif /* CTRL_H */
-- 
2.7.4

[PATCH v2 2/2] crypto: caam - allow retrieving 'era' from register

[Fabio Estevam]

From: Fabio Estevam 

The 'era' information can be retrieved from CAAM registers, so
introduce a caam_get_era_from_hw() function that gets it via register
reads in case the 'fsl,sec-era' property is not passed in the device
tree.

This function is based on the U-Boot implementation from
drivers/crypto/fsl/sec.c

Signed-off-by: Fabio Estevam 
---
Changes since v1:
- None. I previously asked to put the linux-crypto list on Cc

 drivers/crypto/caam/ctrl.c | 45 ++---
 drivers/crypto/caam/regs.h |  6 ++
 2 files changed, 48 insertions(+), 3 deletions(-)

diff --git a/drivers/crypto/caam/ctrl.c b/drivers/crypto/caam/ctrl.c
index bee690a..3f10791 100644
--- a/drivers/crypto/caam/ctrl.c
+++ b/drivers/crypto/caam/ctrl.c
@@ -396,11 +396,47 @@ static void kick_trng(struct platform_device *pdev, int 
ent_delay)
clrsetbits_32(>rtmctl, RTMCTL_PRGM, RTMCTL_SAMP_MODE_RAW_ES_SC);
 }
 
+static u8 caam_get_era_from_hw(struct caam_ctrl __iomem *ctrl)
+{
+   const struct sec_vid id[] = {
+   {0x0A10, 1, 1},
+   {0x0A10, 2, 2},
+   {0x0A12, 1, 3},
+   {0x0A14, 1, 3},
+   {0x0A14, 2, 4},
+   {0x0A16, 1, 4},
+   {0x0A10, 3, 4},
+   {0x0A11, 1, 4},
+   {0x0A18, 1, 4},
+   {0x0A11, 2, 5},
+   {0x0A12, 2, 5},
+   {0x0A13, 1, 5},
+   {0x0A1C, 1, 5},
+   };
+   int i;
+
+   u32 secvid_ms = rd_reg32(>perfmon.caam_id_ms);
+   u32 ccbvid = rd_reg32(>perfmon.ccb_id);
+   u16 ip_id = (secvid_ms & SECVID_MS_IPID_MASK) >> SECVID_MS_IPID_SHIFT;
+   u8 maj_rev = (secvid_ms & SECVID_MS_MAJ_REV_MASK) >>
+ SECVID_MS_MAJ_REV_SHIFT;
+   u8 era = (ccbvid & CCBVID_ERA_MASK) >> CCBVID_ERA_SHIFT;
+
+   if (era)/* This is '0' prior to CAAM ERA-6 */
+   return era;
+
+   for (i = 0; i < ARRAY_SIZE(id); i++)
+   if (id[i].ip_id == ip_id && id[i].maj_rev == maj_rev)
+   return id[i].min_rev;
+
+   return 0;
+}
+
 /**
  * caam_get_era() - Return the ERA of the SEC on SoC, based
  * on "sec-era" propery in the DTS. This property is updated by u-boot.
  **/
-static int caam_get_era(void)
+static int caam_get_era(struct caam_ctrl __iomem *ctrl)
 {
struct device_node *caam_node;
int ret;
@@ -410,7 +446,10 @@ static int caam_get_era(void)
ret = of_property_read_u32(caam_node, "fsl,sec-era", );
of_node_put(caam_node);
 
-   return ret ? -ENOTSUPP : prop;
+   if (!ret)
+   return prop;
+   else
+   return caam_get_era_from_hw(ctrl);
 }
 
 static const struct of_device_id caam_match[] = {
@@ -622,7 +661,7 @@ static int caam_probe(struct platform_device *pdev)
goto iounmap_ctrl;
}
 
-   ctrlpriv->era = caam_get_era();
+   ctrlpriv->era = caam_get_era(ctrl);
 
ret = of_platform_populate(nprop, caam_match, NULL, dev);
if (ret) {
diff --git a/drivers/crypto/caam/regs.h b/drivers/crypto/caam/regs.h
index fee3638..6f96d7b 100644
--- a/drivers/crypto/caam/regs.h
+++ b/drivers/crypto/caam/regs.h
@@ -311,6 +311,12 @@ struct caam_perfmon {
u64 rsvd3;
 
/* Component Instantiation Parameters   fe0-fff */
+#define SECVID_MS_IPID_MASK0x
+#define SECVID_MS_IPID_SHIFT   16
+#define SECVID_MS_MAJ_REV_MASK 0xff00
+#define SECVID_MS_MAJ_REV_SHIFT8
+#define CCBVID_ERA_MASK0xff00
+#define CCBVID_ERA_SHIFT   24
u32 rtic_id;/* RVID - RTIC Version ID   */
u32 ccb_id; /* CCBVID - CCB Version ID  */
u32 cha_id_ms;  /* CHAVID - CHA Version ID Most Significant*/
-- 
2.7.4

Re: CAAM and IMA/EVM : caam_rsa_enc: DECO: desc idx 7: Protocol Size Error

[James Bottomley]

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

[Martin Townsend]

On Tue, Apr 10, 2018 at 7:43 PM, Martin Townsend
<mtownsend1...@gmail.com> wrote:
> Hi Fabio,
>
> On Tue, Apr 10, 2018 at 7:22 PM, Fabio Estevam <feste...@gmail.com> wrote:
>> Hi Martin,
>>
>> On Tue, Apr 10, 2018 at 2:06 PM, Martin Townsend
>> <mtownsend1...@gmail.com> wrote:
>>> Hi Fabio,
>>>
>>> On Tue, Apr 10, 2018 at 5:59 PM, Fabio Estevam <feste...@gmail.com> wrote:
>>>> Hi Martin,
>>>>
>>>> On Mon, Apr 9, 2018 at 5:41 AM, Martin Townsend <mtownsend1...@gmail.com> 
>>>> 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
>> r

Re: CAAM and IMA/EVM : caam_rsa_enc: DECO: desc idx 7: Protocol Size Error

[Martin Townsend]

Hi Fabio,

On Tue, Apr 10, 2018 at 7:22 PM, Fabio Estevam <feste...@gmail.com> wrote:
> Hi Martin,
>
> On Tue, Apr 10, 2018 at 2:06 PM, Martin Townsend
> <mtownsend1...@gmail.com> wrote:
>> Hi Fabio,
>>
>> On Tue, Apr 10, 2018 at 5:59 PM, Fabio Estevam <feste...@gmail.com> wrote:
>>> Hi Martin,
>>>
>>> On Mon, Apr 9, 2018 at 5:41 AM, Martin Townsend <mtownsend1...@gmail.com> 
>>> 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 []
> (

Re: CAAM and IMA/EVM : caam_rsa_enc: DECO: desc idx 7: Protocol Size Error

[Fabio Estevam]

Hi Martin,

On Tue, Apr 10, 2018 at 2:06 PM, Martin Townsend
<mtownsend1...@gmail.com> wrote:
> Hi Fabio,
>
> On Tue, Apr 10, 2018 at 5:59 PM, Fabio Estevam <feste...@gmail.com> wrote:
>> Hi Martin,
>>
>> On Mon, Apr 9, 2018 at 5:41 AM, Martin Townsend <mtownsend1...@gmail.com> 
>> 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.3

Re: CAAM and IMA/EVM : caam_rsa_enc: DECO: desc idx 7: Protocol Size Error

[Martin Townsend]

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

[Fabio Estevam]

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: [PATCH] crypto: DRBG - guard uninstantion by lock

[Stephan Mueller]

Am Dienstag, 10. April 2018, 17:23:46 CEST schrieb Dmitry Vyukov:

Hi Dmitry,

> Stephan,
> 
> Do you have any hypothesis as to why this is not detected by KASAN and
> causes silent corruptions?
> We generally try to understand such cases and improve KASAN so that it
> catches such cases more reliably and they do not cause splashes of
> random crashes on syzbot.

I do not have any hypothesis at this point. I know that you induce some fault. 
As you mentioned the drbg_kcapi_seed function, I was looking through the error 
code paths to see whether some error handlers trip over each other. But all is 
guesswork so far. And I am not even sure whether the bug is in the DRBG code 
base.

Looking into the trace you sent, I see a NULL pointer dereference. At one 
point there is also the drbg_init_hash_kernel that is called. But nowhere I 
see any smoking gun.

Could you please give me a description of the fault you are inducing?

Ciao
Stephan

Re: [PATCH] crypto: DRBG - guard uninstantion by lock

[Dmitry Vyukov]

On Mon, Apr 9, 2018 at 9:57 AM, Dmitry Vyukov  wrote:
> On Mon, Apr 9, 2018 at 7:40 AM, Stephan Mueller  wrote:
>> Am Montag, 9. April 2018, 00:46:03 CEST schrieb Theodore Y. Ts'o:
>>
>> Hi Theodore,
>>>
>>> So the syzbot will run while the patch goes through the normal e-mail
>>> review process, which is kind of neat.  :-)
>>
>> Thank you very much for the hint. That is a neat feature indeed.
>>
>> As I came late to the party and I missed the original mails, I am wondering
>> about which GIT repo was used and which branch of it. With that, I would be
>> happy to resubmit with the test line.
>
> All syzbot reported bugs are available here:
> https://groups.google.com/forum/#!searchin/syzkaller-bugs/"WARNING$20in$20kmem_cache_free;
> and here:
> https://syzkaller.appspot.com/
>
> But unfortunately testing won't work in this case, because I manually
> extracted a reproducer and syzbot does not know about it. This bug
> seems to lead to assorted silent heap corruptions and different
> manifestations each time, so it's difficult for syzbot to attribute a
> reproducer to the bug. When we debug it, it would be nice to
> understand why the heap corruption is silent and is not detected by
> KASAN and anything else, to prevent such unpleasant cases in future.
>
> I've tested it manually, but unfortunately kernel still crashed within a 
> minute:

Stephan,

Do you have any hypothesis as to why this is not detected by KASAN and
causes silent corruptions?
We generally try to understand such cases and improve KASAN so that it
catches such cases more reliably and they do not cause splashes of
random crashes on syzbot.

Thanks



> $ git status
> HEAD detached at f2d285669aae
> Changes not staged for commit:
>   (use "git add ..." to update what will be committed)
>   (use "git checkout -- ..." to discard changes in working directory)
>
> modified:   crypto/drbg.c
>
> $ git diff
> diff --git a/crypto/drbg.c b/crypto/drbg.c
> index 4faa2781c964..68c1949a253f 100644
> --- a/crypto/drbg.c
> +++ b/crypto/drbg.c
> @@ -1510,8 +1510,8 @@ static int drbg_instantiate(struct drbg_state
> *drbg, struct drbg_string *pers,
> return ret;
>
>  free_everything:
> -   mutex_unlock(>drbg_mutex);
> drbg_uninstantiate(drbg);
> +   mutex_unlock(>drbg_mutex);
> return ret;
>  }
>
> # ./a.out
> ...
> [  183.647874] FAULT_INJECTION: forcing a failure.
> [  183.647874] name failslab, interval 1, probability 0, space 0, times 0
> [  183.648287] Call Trace:
> [  183.648297]  dump_stack+0x1b9/0x29f
> [  183.648306]  ? arch_local_irq_restore+0x52/0x52
> [  183.648318]  ? __save_stack_trace+0x7e/0xd0
> [  183.651848]  should_fail.cold.4+0xa/0x1a
> [  183.652411]  ? fault_create_debugfs_attr+0x1f0/0x1f0
> [  183.653138]  ? kasan_kmalloc+0xc4/0xe0
> [  183.653694]  ? __kmalloc+0x14e/0x760
> [  183.654206]  ? drbg_kcapi_seed+0x776/0x12e0
> [  183.654798]  ? crypto_rng_reset+0x7c/0x130
> [  183.655379]  ? rng_setkey+0x25/0x30
> [  183.655882]  ? alg_setsockopt+0x306/0x3b0
> [  183.656450]  ? graph_lock+0x170/0x170
> [  183.656975]  ? entry_SYSENTER_compat+0x70/0x7f
> [  183.657606]  ? find_held_lock+0x36/0x1c0
> [  183.658164]  ? __lock_is_held+0xb5/0x140
> [  183.658728]  ? check_same_owner+0x320/0x320
> [  183.659321]  ? rcu_note_context_switch+0x710/0x710
> [  183.66]  should_failslab+0x124/0x180
> [  183.660561]  __kmalloc+0x2c8/0x760
> [  183.661046]  ? graph_lock+0x170/0x170
> [  183.661569]  ? drbg_kcapi_seed+0x882/0x12e0
> [  183.662161]  drbg_kcapi_seed+0x882/0x12e0
> [  183.662731]  ? drbg_seed+0x10a0/0x10a0
> [  183.663267]  ? lock_downgrade+0x8e0/0x8e0
> [  183.663833]  ? lock_acquire+0x1dc/0x520
> [  183.664385]  ? lock_release+0xa10/0xa10
> [  183.664934]  ? check_same_owner+0x320/0x320
> [  183.665530]  ? __sanitizer_cov_trace_const_cmp8+0x18/0x20
> [  183.666292]  ? __check_object_size+0x95/0x5d9
> [  183.666904]  ? sock_kmalloc+0x14e/0x1d0
> [  183.667444]  ? mark_held_locks+0xc9/0x160
> [  183.668020]  ? __might_sleep+0x95/0x190
> [  183.668567]  crypto_rng_reset+0x7c/0x130
> [  183.669124]  rng_setkey+0x25/0x30
> [  183.669598]  ? rng_sock_destruct+0x90/0x90
> [  183.670176]  alg_setsockopt+0x306/0x3b0
> [  183.670724]  __compat_sys_setsockopt+0x315/0x7c0
> [  183.671375]  ? __compat_sys_getsockopt+0x7f0/0x7f0
> [  183.672057]  ? __sanitizer_cov_trace_const_cmp4+0x16/0x20
> [  183.672813]  ? ksys_write+0x1a6/0x250
> [  183.67]  ? SyS_read+0x30/0x30
> [  183.673811]  compat_SyS_setsockopt+0x34/0x50
> [  183.674416]  ? scm_detach_fds_compat+0x440/0x440
> [  183.675079]  do_fast_syscall_32+0x41f/0x10dc
> [  183.675725]  ? do_page_fault+0xee/0x8a7
> [  183.676284]  ? do_int80_syscall_32+0xa70/0xa70
> [  183.676925]  ? trace_hardirqs_on_thunk+0x1a/0x1c
> [  183.677590]  ? __sanitizer_cov_trace_const_cmp4+0x16/0x20
> [  183.678348]  ? syscall_return_slowpath+0x30f/0x5c0
> [  183.679026]  ? sysret32_from_system_call+0x5/0x3c
> [  183.679694]  ?