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

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

[Martin Townsend]

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: 40000789: 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 2140000.caam: ERA source: CCBVID.
caam 2140000.caam: Entropy delay = 3200
caam 2140000.caam: Instantiated RNG4 SH0
caam 2140000.caam: Instantiated RNG4 SH1
caam 2140000.caam: device ID = 0x0a16030000000000 (Era 8)
caam 2140000.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 2140000.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: 40000789: 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 what this means, I've created my
certificate using openssl and a configuration file (shown below) that
set the keysize to 2048 bits so I'm not sure how the signature in the
x509 is greater than the RSA modulus which in my limited understanding
is the key size in bits.

I added the following to public_key_verify_signature()

printk("%s: Public Key: Keylen: %u\n", __func__, pkey->keylen);
printk("%s: Signature: %u\n", __func__, sig->s_size);

and get

public_key_verify_signature: Public Key: Keylen: 270
public_key_verify_signature: Signature: 257

I'm assuming they are both in bytes which kind of suggests the key
length is larger than the signature but then again this keylen may
include other information.  I'm a bit suspicious of the signature
length of 257 maybe this is causing the problem which could point to
creating the certificate incorrectly??  Here's the configuration I'm
using for the root cert:
[ ca ]
default_ca                      = CA_default

[ CA_default ]
dir                             = ./ca

certs                           = $dir/certsdb                  #
Where the issued certs are kept
new_certs_dir                   = $certs                        #
default place for new certs.
database                        = $dir/certdbindex.txt          #
database index file.
certificate                     = $dir/certs/ima-local-ca.x509  # The
CA certificate
private_key                     = $dir/private/ca-privkey.pem   # The
private key
default_days                    = 3650
default_md                      = sha256
preserve                        = no
email_in_dn                     = no
nameopt                         = default_ca
certopt                         = default_ca
policy                          = policy_ima_ca

[ policy_ima_ca ]
countryName                     = match                   # Must be
the same as the CA
stateOrProvinceName             = match                   # Must be
the same as the CA
organizationName                = supplied
organizationalUnitName          = optional
commonName                      = supplied                # Must be there
emailAddress                    = optional

[ req ]
default_bits                    = 2048                    # Size of keys
default_keyfile                 = privkey.pem             # name of
generated keys
string_mask                     = utf8only                # permitted characters
distinguished_name              = req_distinguished_name  # where to
get DN for reqs
prompt                          = no                      # No prompting
x509_extensions                 = v3_ca                   # The
extentions to add to self signed certs
req_extensions                  = v3_req                  # The
extensions to add to req's

[ req_distinguished_name ]
O                               = xxx
OU                              = IMA
CN                              = xxx IMA-EVM Root CA
emailAddress                    = ca-ima-evm@xxx.com
L                               = xxx
ST                              = Dorset
C                               = xxx

[ v3_ca ]
basicConstraints                = CA:TRUE
subjectKeyIdentifier            = hash
authorityKeyIdentifier          = keyid:always,issuer:always
subjectAltName                  = email:move

[ v3_req ]
subjectAltName=email:move


Then the openssl (1.0.2n  7 Dec 2017) command to create the self
signed root CA certificate.

openssl req -new -x509 -utf8 -sha256 \
            -days $((365 * $duration)) \
            -passout file:$rootcadir/private/key_pass.txt \
            -keyout $rootca_privkey \
            -outform DER \
            -out $rootca_pubcert_der \
            -config $rootcadir/$ima_root_openssl_cnf

I'm not sure what I can do further to debug this so any help or
suggestions would be really appreciated.  If there is any further
debug that would help let me know and I'll try it out.

Many Thanks,
Martin.

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

[Mimi Zohar]

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: 40000789: 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 2140000.caam: ERA source: CCBVID.
> caam 2140000.caam: Entropy delay = 3200
> caam 2140000.caam: Instantiated RNG4 SH0
> caam 2140000.caam: Instantiated RNG4 SH1
> caam 2140000.caam: device ID = 0x0a16030000000000 (Era 8)
> caam 2140000.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 2140000.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: 40000789: 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 what this means, I've created my
> certificate using openssl and a configuration file (shown below) that
> set the keysize to 2048 bits so I'm not sure how the signature in the
> x509 is greater than the RSA modulus which in my limited understanding
> is the key size in bits.
> 
> I added the following to public_key_verify_signature()
> 
> printk("%s: Public Key: Keylen: %u\n", __func__, pkey->keylen);
> printk("%s: Signature: %u\n", __func__, sig->s_size);
> 
> and get
> 
> public_key_verify_signature: Public Key: Keylen: 270
> public_key_verify_signature: Signature: 257
> 
> I'm assuming they are both in bytes which kind of suggests the key
> length is larger than the signature but then again this keylen may
> include other information.  I'm a bit suspicious of the signature
> length of 257 maybe this is causing the problem which could point to
> creating the certificate incorrectly??  Here's the configuration I'm
> using for the root cert:
> [ ca ]
> default_ca                      = CA_default
> 
> [ CA_default ]
> dir                             = ./ca
> 
> certs                           = $dir/certsdb                  #
> Where the issued certs are kept
> new_certs_dir                   = $certs                        #
> default place for new certs.
> database                        = $dir/certdbindex.txt          #
> database index file.
> certificate                     = $dir/certs/ima-local-ca.x509  # The
> CA certificate
> private_key                     = $dir/private/ca-privkey.pem   # The
> private key
> default_days                    = 3650
> default_md                      = sha256
> preserve                        = no
> email_in_dn                     = no
> nameopt                         = default_ca
> certopt                         = default_ca
> policy                          = policy_ima_ca
> 
> [ policy_ima_ca ]
> countryName                     = match                   # Must be
> the same as the CA
> stateOrProvinceName             = match                   # Must be
> the same as the CA
> organizationName                = supplied
> organizationalUnitName          = optional
> commonName                      = supplied                # Must be there
> emailAddress                    = optional
> 
> [ req ]
> default_bits                    = 2048                    # Size of keys
> default_keyfile                 = privkey.pem             # name of
> generated keys
> string_mask                     = utf8only                # permitted characters
> distinguished_name              = req_distinguished_name  # where to
> get DN for reqs
> prompt                          = no                      # No prompting
> x509_extensions                 = v3_ca                   # The
> extentions to add to self signed certs
> req_extensions                  = v3_req                  # The
> extensions to add to req's
> 
> [ req_distinguished_name ]
> O                               = xxx
> OU                              = IMA
> CN                              = xxx IMA-EVM Root CA
> emailAddress                    = ca-ima-evm@xxx.com
> L                               = xxx
> ST                              = Dorset
> C                               = xxx
> 
> [ v3_ca ]
> basicConstraints                = CA:TRUE
> subjectKeyIdentifier            = hash
> authorityKeyIdentifier          = keyid:always,issuer:always
> subjectAltName                  = email:move
> 
> [ v3_req ]
> subjectAltName=email:move
> 
> 
> Then the openssl (1.0.2n  7 Dec 2017) command to create the self
> signed root CA certificate.
> 
> openssl req -new -x509 -utf8 -sha256 \
>             -days $((365 * $duration)) \
>             -passout file:$rootcadir/private/key_pass.txt \
>             -keyout $rootca_privkey \
>             -outform DER \
>             -out $rootca_pubcert_der \
>             -config $rootcadir/$ima_root_openssl_cnf
> 
> I'm not sure what I can do further to debug this so any help or
> suggestions would be really appreciated.  If there is any further
> debug that would help let me know and I'll try it out.
> 
> Many Thanks,
> Martin.
> 

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

[Martin Townsend]

Hi Mimi,

On Mon, Apr 9, 2018 at 1:46 PM, Mimi Zohar <zohar@linux.vnet.ibm.com> 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: 40000789: 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 2140000.caam: ERA source: CCBVID.
>> caam 2140000.caam: Entropy delay = 3200
>> caam 2140000.caam: Instantiated RNG4 SH0
>> caam 2140000.caam: Instantiated RNG4 SH1
>> caam 2140000.caam: device ID = 0x0a16030000000000 (Era 8)
>> caam 2140000.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 2140000.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: 40000789: 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 what this means, I've created my
>> certificate using openssl and a configuration file (shown below) that
>> set the keysize to 2048 bits so I'm not sure how the signature in the
>> x509 is greater than the RSA modulus which in my limited understanding
>> is the key size in bits.
>>
>> I added the following to public_key_verify_signature()
>>
>> printk("%s: Public Key: Keylen: %u\n", __func__, pkey->keylen);
>> printk("%s: Signature: %u\n", __func__, sig->s_size);
>>
>> and get
>>
>> public_key_verify_signature: Public Key: Keylen: 270
>> public_key_verify_signature: Signature: 257
>>
>> I'm assuming they are both in bytes which kind of suggests the key
>> length is larger than the signature but then again this keylen may
>> include other information.  I'm a bit suspicious of the signature
>> length of 257 maybe this is causing the problem which could point to
>> creating the certificate incorrectly??  Here's the configuration I'm
>> using for the root cert:
>> [ ca ]
>> default_ca                      = CA_default
>>
>> [ CA_default ]
>> dir                             = ./ca
>>
>> certs                           = $dir/certsdb                  #
>> Where the issued certs are kept
>> new_certs_dir                   = $certs                        #
>> default place for new certs.
>> database                        = $dir/certdbindex.txt          #
>> database index file.
>> certificate                     = $dir/certs/ima-local-ca.x509  # The
>> CA certificate
>> private_key                     = $dir/private/ca-privkey.pem   # The
>> private key
>> default_days                    = 3650
>> default_md                      = sha256
>> preserve                        = no
>> email_in_dn                     = no
>> nameopt                         = default_ca
>> certopt                         = default_ca
>> policy                          = policy_ima_ca
>>
>> [ policy_ima_ca ]
>> countryName                     = match                   # Must be
>> the same as the CA
>> stateOrProvinceName             = match                   # Must be
>> the same as the CA
>> organizationName                = supplied
>> organizationalUnitName          = optional
>> commonName                      = supplied                # Must be there
>> emailAddress                    = optional
>>
>> [ req ]
>> default_bits                    = 2048                    # Size of keys
>> default_keyfile                 = privkey.pem             # name of
>> generated keys
>> string_mask                     = utf8only                # permitted characters
>> distinguished_name              = req_distinguished_name  # where to
>> get DN for reqs
>> prompt                          = no                      # No prompting
>> x509_extensions                 = v3_ca                   # The
>> extentions to add to self signed certs
>> req_extensions                  = v3_req                  # The
>> extensions to add to req's
>>
>> [ req_distinguished_name ]
>> O                               = xxx
>> OU                              = IMA
>> CN                              = xxx IMA-EVM Root CA
>> emailAddress                    = ca-ima-evm@xxx.com
>> L                               = xxx
>> ST                              = Dorset
>> C                               = xxx
>>
>> [ v3_ca ]
>> basicConstraints                = CA:TRUE
>> subjectKeyIdentifier            = hash
>> authorityKeyIdentifier          = keyid:always,issuer:always
>> subjectAltName                  = email:move
>>
>> [ v3_req ]
>> subjectAltName=email:move
>>
>>
>> Then the openssl (1.0.2n  7 Dec 2017) command to create the self
>> signed root CA certificate.
>>
>> openssl req -new -x509 -utf8 -sha256 \
>>             -days $((365 * $duration)) \
>>             -passout file:$rootcadir/private/key_pass.txt \
>>             -keyout $rootca_privkey \
>>             -outform DER \
>>             -out $rootca_pubcert_der \
>>             -config $rootcadir/$ima_root_openssl_cnf
>>
>> I'm not sure what I can do further to debug this so any help or
>> suggestions would be really appreciated.  If there is any further
>> debug that would help let me know and I'll try it out.
>>
>> Many Thanks,
>> Martin.
>>
>

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

[Mimi Zohar]

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 <zohar@linux.vnet.ibm.com> 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: 40000789: 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 2140000.caam: ERA source: CCBVID.
> >> caam 2140000.caam: Entropy delay = 3200
> >> caam 2140000.caam: Instantiated RNG4 SH0
> >> caam 2140000.caam: Instantiated RNG4 SH1
> >> caam 2140000.caam: device ID = 0x0a16030000000000 (Era 8)
> >> caam 2140000.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 2140000.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: 40000789: 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 what this means, I've created my
> >> certificate using openssl and a configuration file (shown below) that
> >> set the keysize to 2048 bits so I'm not sure how the signature in the
> >> x509 is greater than the RSA modulus which in my limited understanding
> >> is the key size in bits.
> >>
> >> I added the following to public_key_verify_signature()
> >>
> >> printk("%s: Public Key: Keylen: %u\n", __func__, pkey->keylen);
> >> printk("%s: Signature: %u\n", __func__, sig->s_size);
> >>
> >> and get
> >>
> >> public_key_verify_signature: Public Key: Keylen: 270
> >> public_key_verify_signature: Signature: 257
> >>
> >> I'm assuming they are both in bytes which kind of suggests the key
> >> length is larger than the signature but then again this keylen may
> >> include other information.  I'm a bit suspicious of the signature
> >> length of 257 maybe this is causing the problem which could point to
> >> creating the certificate incorrectly??  Here's the configuration I'm
> >> using for the root cert:
> >> [ ca ]
> >> default_ca                      = CA_default
> >>
> >> [ CA_default ]
> >> dir                             = ./ca
> >>
> >> certs                           = $dir/certsdb                  #
> >> Where the issued certs are kept
> >> new_certs_dir                   = $certs                        #
> >> default place for new certs.
> >> database                        = $dir/certdbindex.txt          #
> >> database index file.
> >> certificate                     = $dir/certs/ima-local-ca.x509  # The
> >> CA certificate
> >> private_key                     = $dir/private/ca-privkey.pem   # The
> >> private key
> >> default_days                    = 3650
> >> default_md                      = sha256
> >> preserve                        = no
> >> email_in_dn                     = no
> >> nameopt                         = default_ca
> >> certopt                         = default_ca
> >> policy                          = policy_ima_ca
> >>
> >> [ policy_ima_ca ]
> >> countryName                     = match                   # Must be
> >> the same as the CA
> >> stateOrProvinceName             = match                   # Must be
> >> the same as the CA
> >> organizationName                = supplied
> >> organizationalUnitName          = optional
> >> commonName                      = supplied                # Must be there
> >> emailAddress                    = optional
> >>
> >> [ req ]
> >> default_bits                    = 2048                    # Size of keys
> >> default_keyfile                 = privkey.pem             # name of
> >> generated keys
> >> string_mask                     = utf8only                # permitted characters
> >> distinguished_name              = req_distinguished_name  # where to
> >> get DN for reqs
> >> prompt                          = no                      # No prompting
> >> x509_extensions                 = v3_ca                   # The
> >> extentions to add to self signed certs
> >> req_extensions                  = v3_req                  # The
> >> extensions to add to req's
> >>
> >> [ req_distinguished_name ]
> >> O                               = xxx
> >> OU                              = IMA
> >> CN                              = xxx IMA-EVM Root CA
> >> emailAddress                    = ca-ima-evm@xxx.com
> >> L                               = xxx
> >> ST                              = Dorset
> >> C                               = xxx
> >>
> >> [ v3_ca ]
> >> basicConstraints                = CA:TRUE
> >> subjectKeyIdentifier            = hash
> >> authorityKeyIdentifier          = keyid:always,issuer:always
> >> subjectAltName                  = email:move
> >>
> >> [ v3_req ]
> >> subjectAltName=email:move
> >>
> >>
> >> Then the openssl (1.0.2n  7 Dec 2017) command to create the self
> >> signed root CA certificate.
> >>
> >> openssl req -new -x509 -utf8 -sha256 \
> >>             -days $((365 * $duration)) \
> >>             -passout file:$rootcadir/private/key_pass.txt \
> >>             -keyout $rootca_privkey \
> >>             -outform DER \
> >>             -out $rootca_pubcert_der \
> >>             -config $rootcadir/$ima_root_openssl_cnf
> >>
> >> I'm not sure what I can do further to debug this so any help or
> >> suggestions would be really appreciated.  If there is any further
> >> debug that would help let me know and I'll try it out.
> >>
> >> Many Thanks,
> >> Martin.
> >>
> >
> 

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

[Mike Rapoport]

(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 <zohar@linux.vnet.ibm.com> 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 2140000.caam: ERA source: CCBVID.
> >> caam 2140000.caam: Entropy delay = 3200
> >> caam 2140000.caam: Instantiated RNG4 SH0
> >> caam 2140000.caam: Instantiated RNG4 SH1
> >> caam 2140000.caam: device ID = 0x0a16030000000000 (Era 8)
> >> caam 2140000.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 2140000.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: 40000789: 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 what this means, I've created my
> >> certificate using openssl and a configuration file (shown below) that
> >> set the keysize to 2048 bits so I'm not sure how the signature in the
> >> x509 is greater than the RSA modulus which in my limited understanding
> >> is the key size in bits.
> >>
> >> I added the following to public_key_verify_signature()
> >>
> >> printk("%s: Public Key: Keylen: %u\n", __func__, pkey->keylen);
> >> printk("%s: Signature: %u\n", __func__, sig->s_size);
> >>
> >> and get
> >>
> >> public_key_verify_signature: Public Key: Keylen: 270
> >> public_key_verify_signature: Signature: 257
> >>
> >> I'm assuming they are both in bytes which kind of suggests the key
> >> length is larger than the signature but then again this keylen may
> >> include other information.  I'm a bit suspicious of the signature
> >> length of 257 maybe this is causing the problem which could point to
> >> creating the certificate incorrectly??  Here's the configuration I'm
> >> using for the root cert:
> >> [ ca ]
> >> default_ca                      = CA_default
> >>
> >> [ CA_default ]
> >> dir                             = ./ca
> >>
> >> certs                           = $dir/certsdb                  #
> >> Where the issued certs are kept
> >> new_certs_dir                   = $certs                        #
> >> default place for new certs.
> >> database                        = $dir/certdbindex.txt          #
> >> database index file.
> >> certificate                     = $dir/certs/ima-local-ca.x509  # The
> >> CA certificate
> >> private_key                     = $dir/private/ca-privkey.pem   # The
> >> private key
> >> default_days                    = 3650
> >> default_md                      = sha256
> >> preserve                        = no
> >> email_in_dn                     = no
> >> nameopt                         = default_ca
> >> certopt                         = default_ca
> >> policy                          = policy_ima_ca
> >>
> >> [ policy_ima_ca ]
> >> countryName                     = match                   # Must be
> >> the same as the CA
> >> stateOrProvinceName             = match                   # Must be
> >> the same as the CA
> >> organizationName                = supplied
> >> organizationalUnitName          = optional
> >> commonName                      = supplied                # Must be there
> >> emailAddress                    = optional
> >>
> >> [ req ]
> >> default_bits                    = 2048                    # Size of keys
> >> default_keyfile                 = privkey.pem             # name of
> >> generated keys
> >> string_mask                     = utf8only                # permitted characters
> >> distinguished_name              = req_distinguished_name  # where to
> >> get DN for reqs
> >> prompt                          = no                      # No prompting
> >> x509_extensions                 = v3_ca                   # The
> >> extentions to add to self signed certs
> >> req_extensions                  = v3_req                  # The
> >> extensions to add to req's
> >>
> >> [ req_distinguished_name ]
> >> O                               = xxx
> >> OU                              = IMA
> >> CN                              = xxx IMA-EVM Root CA
> >> emailAddress                    = ca-ima-evm@xxx.com
> >> L                               = xxx
> >> ST                              = Dorset
> >> C                               = xxx
> >>
> >> [ v3_ca ]
> >> basicConstraints                = CA:TRUE
> >> subjectKeyIdentifier            = hash
> >> authorityKeyIdentifier          = keyid:always,issuer:always
> >> subjectAltName                  = email:move
> >>
> >> [ v3_req ]
> >> subjectAltName=email:move
> >>
> >>
> >> Then the openssl (1.0.2n  7 Dec 2017) command to create the self
> >> signed root CA certificate.
> >>
> >> openssl req -new -x509 -utf8 -sha256 \
> >>             -days $((365 * $duration)) \
> >>             -passout file:$rootcadir/private/key_pass.txt \
> >>             -keyout $rootca_privkey \
> >>             -outform DER \
> >>             -out $rootca_pubcert_der \
> >>             -config $rootcadir/$ima_root_openssl_cnf
> >>
> >> I'm not sure what I can do further to debug this so any help or
> >> suggestions would be really appreciated.  If there is any further
> >> debug that would help let me know and I'll try it out.
> >>
> >> Many Thanks,
> >> Martin.
> >>
> >
> 

-- 
Sincerely yours,
Mike.

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

[Martin Townsend]

Hi Mike,

On Mon, Apr 9, 2018 at 5:53 PM, Mike Rapoport <rppt@linux.vnet.ibm.com> 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 <zohar@linux.vnet.ibm.com> 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 2140000.caam: ERA source: CCBVID.
>> >> caam 2140000.caam: Entropy delay = 3200
>> >> caam 2140000.caam: Instantiated RNG4 SH0
>> >> caam 2140000.caam: Instantiated RNG4 SH1
>> >> caam 2140000.caam: device ID = 0x0a16030000000000 (Era 8)
>> >> caam 2140000.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 2140000.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: 40000789: 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 what this means, I've created my
>> >> certificate using openssl and a configuration file (shown below) that
>> >> set the keysize to 2048 bits so I'm not sure how the signature in the
>> >> x509 is greater than the RSA modulus which in my limited understanding
>> >> is the key size in bits.
>> >>
>> >> I added the following to public_key_verify_signature()
>> >>
>> >> printk("%s: Public Key: Keylen: %u\n", __func__, pkey->keylen);
>> >> printk("%s: Signature: %u\n", __func__, sig->s_size);
>> >>
>> >> and get
>> >>
>> >> public_key_verify_signature: Public Key: Keylen: 270
>> >> public_key_verify_signature: Signature: 257
>> >>
>> >> I'm assuming they are both in bytes which kind of suggests the key
>> >> length is larger than the signature but then again this keylen may
>> >> include other information.  I'm a bit suspicious of the signature
>> >> length of 257 maybe this is causing the problem which could point to
>> >> creating the certificate incorrectly??  Here's the configuration I'm
>> >> using for the root cert:
>> >> [ ca ]
>> >> default_ca                      = CA_default
>> >>
>> >> [ CA_default ]
>> >> dir                             = ./ca
>> >>
>> >> certs                           = $dir/certsdb                  #
>> >> Where the issued certs are kept
>> >> new_certs_dir                   = $certs                        #
>> >> default place for new certs.
>> >> database                        = $dir/certdbindex.txt          #
>> >> database index file.
>> >> certificate                     = $dir/certs/ima-local-ca.x509  # The
>> >> CA certificate
>> >> private_key                     = $dir/private/ca-privkey.pem   # The
>> >> private key
>> >> default_days                    = 3650
>> >> default_md                      = sha256
>> >> preserve                        = no
>> >> email_in_dn                     = no
>> >> nameopt                         = default_ca
>> >> certopt                         = default_ca
>> >> policy                          = policy_ima_ca
>> >>
>> >> [ policy_ima_ca ]
>> >> countryName                     = match                   # Must be
>> >> the same as the CA
>> >> stateOrProvinceName             = match                   # Must be
>> >> the same as the CA
>> >> organizationName                = supplied
>> >> organizationalUnitName          = optional
>> >> commonName                      = supplied                # Must be there
>> >> emailAddress                    = optional
>> >>
>> >> [ req ]
>> >> default_bits                    = 2048                    # Size of keys
>> >> default_keyfile                 = privkey.pem             # name of
>> >> generated keys
>> >> string_mask                     = utf8only                # permitted characters
>> >> distinguished_name              = req_distinguished_name  # where to
>> >> get DN for reqs
>> >> prompt                          = no                      # No prompting
>> >> x509_extensions                 = v3_ca                   # The
>> >> extentions to add to self signed certs
>> >> req_extensions                  = v3_req                  # The
>> >> extensions to add to req's
>> >>
>> >> [ req_distinguished_name ]
>> >> O                               = xxx
>> >> OU                              = IMA
>> >> CN                              = xxx IMA-EVM Root CA
>> >> emailAddress                    = ca-ima-evm@xxx.com
>> >> L                               = xxx
>> >> ST                              = Dorset
>> >> C                               = xxx
>> >>
>> >> [ v3_ca ]
>> >> basicConstraints                = CA:TRUE
>> >> subjectKeyIdentifier            = hash
>> >> authorityKeyIdentifier          = keyid:always,issuer:always
>> >> subjectAltName                  = email:move
>> >>
>> >> [ v3_req ]
>> >> subjectAltName=email:move
>> >>
>> >>
>> >> Then the openssl (1.0.2n  7 Dec 2017) command to create the self
>> >> signed root CA certificate.
>> >>
>> >> openssl req -new -x509 -utf8 -sha256 \
>> >>             -days $((365 * $duration)) \
>> >>             -passout file:$rootcadir/private/key_pass.txt \
>> >>             -keyout $rootca_privkey \
>> >>             -outform DER \
>> >>             -out $rootca_pubcert_der \
>> >>             -config $rootcadir/$ima_root_openssl_cnf
>> >>
>> >> I'm not sure what I can do further to debug this so any help or
>> >> suggestions would be really appreciated.  If there is any further
>> >> debug that would help let me know and I'll try it out.
>> >>
>> >> Many Thanks,
>> >> Martin.
>> >>
>> >
>>
>
> --
> Sincerely yours,
> Mike.
>

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 <mtownsend1973@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?

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 <festevam@gmail.com> wrote:
> Hi Martin,
>
> On Mon, Apr 9, 2018 at 5:41 AM, Martin Townsend <mtownsend1973@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,
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 Tue, Apr 10, 2018 at 2:06 PM, Martin Townsend
<mtownsend1973@gmail.com> wrote:
> Hi Fabio,
>
> On Tue, Apr 10, 2018 at 5:59 PM, Fabio Estevam <festevam@gmail.com> wrote:
>> Hi Martin,
>>
>> On Mon, Apr 9, 2018 at 5:41 AM, Martin Townsend <mtownsend1973@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: 40000789: 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-00002-gf0ccf31-dirty #223
[    3.050413] Hardware name: Freescale i.MX6 Ultralite (Device Tree)
[    3.056643] Backtrace:
[    3.059173] [<c010d118>] (dump_backtrace) from [<c010d3d8>]
(show_stack+0x18/0x1c)
[    3.066802]  r7:00000000 r6:60000153 r5:00000000 r4:c107ae78
[    3.072523] [<c010d3c0>] (show_stack) from [<c0a50d24>]
(dump_stack+0xb4/0xe8)
[    3.079810] [<c0a50c70>] (dump_stack) from [<c012618c>] (__warn+0x104/0x130)
[    3.086922]  r9:d604dc94 r8:00000094 r7:00000009 r6:c0d3aea8
r5:00000000 r4:00000000
[    3.094728] [<c0126088>] (__warn) from [<c01262d0>]
(warn_slowpath_null+0x44/0x50)
[    3.102356]  r8:c1008908 r7:d67846c0 r6:c040bbc4 r5:00000094 r4:c0d3aea8
[    3.109120] [<c012628c>] (warn_slowpath_null) from [<c040bbc4>]
(public_key_verify_signature+0x27c/0x2b0)
[    3.118745]  r6:40000789 r5:d6782f00 r4:d6787f40
[    3.123428] [<c040b948>] (public_key_verify_signature) from
[<c040cbd4>] (x509_check_for_self_signed+0xc8/0x104)
[    3.133664]  r10:d602f000 r9:c0bcb1d0 r8:000002a8 r7:d6787f00
r6:d6787f40 r5:00000000
[    3.141543]  r4:d6782d80
[    3.144140] [<c040cb0c>] (x509_check_for_self_signed) from
[<c040bdd0>] (x509_cert_parse+0x11c/0x190)
[    3.153415]  r7:c0bcb1d0 r6:d6787f80 r5:d6782d80 r4:d6787f00
[    3.159138] [<c040bcb4>] (x509_cert_parse) from [<c040c860>]
(x509_key_preparse+0x1c/0x194)
[    3.167550]  r9:c0bcb1d0 r8:c10235dc r7:d604de30 r6:c1026a84
r5:d604de30 r4:c1026af0
[    3.175357] [<c040c844>] (x509_key_preparse) from [<c040adbc>]
(asymmetric_key_preparse+0x50/0x80)
[    3.184376]  r9:c0bcb1d0 r8:c10235dc r7:d604de30 r6:c1026a84
r5:c1008908 r4:c1026af0
[    3.192187] [<c040ad6c>] (asymmetric_key_preparse) from
[<c03e40b4>] (key_create_or_update+0x138/0x404)
[    3.201638]  r7:d6495601 r6:d6495600 r5:c1008908 r4:c1026a8c
[    3.207366] [<c03e3f7c>] (key_create_or_update) from [<c0f5a9c4>]
(regulatory_init_db+0xf4/0x1e8)
[    3.216303]  r10:0000000e r9:1f030000 r8:c0d1d144 r7:c17f1e7c
r6:c0bcb478 r5:000002a8
[    3.224180]  r4:c0bcb1d0
[    3.226780] [<c0f5a8d0>] (regulatory_init_db) from [<c0102764>]
(do_one_initcall+0x50/0x1a4)
[    3.235278]  r10:c0f00630 r9:c0f64858 r8:c107cb00 r7:00000000
r6:c0f5a8d0 r5:c1008908
[    3.243155]  r4:ffffe000
[    3.245753] [<c0102714>] (do_one_initcall) from [<c0f00f04>]
(kernel_init_freeable+0x118/0x1d8)
[    3.254512]  r9:c0f64858 r8:000000f4 r7:c0e1ec98 r6:c0f64854
r5:c107cb00 r4:c0f78f70
[    3.262324] [<c0f00dec>] (kernel_init_freeable) from [<c0a665b8>]
(kernel_init+0x10/0x118)
[    3.270650]  r10:00000000 r9:00000000 r8:00000000 r7:00000000
r6:00000000 r5:c0a665a8
[    3.278527]  r4:00000000
[    3.281127] [<c0a665a8>] (kernel_init) from [<c01010b4>]
(ret_from_fork+0x14/0x20)
[    3.288749] Exception stack(0xd604dfb0 to 0xd604dff8)
[    3.293859] dfa0:                                     00000000
00000000 00000000 00000000
[    3.302098] dfc0: 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000
[    3.310329] dfe0: 00000000 00000000 00000000 00000000 00000013 00000000
[    3.316993]  r5:c0a665a8 r4:00000000
[    3.320825] irq event stamp: 186525
[    3.324504] hardirqs last  enabled at (186543): [<c01803b8>]
console_unlock+0x4d4/0x5c8
[    3.332584] hardirqs last disabled at (186550): [<c017ffac>]
console_unlock+0xc8/0x5c8
[    3.340664] softirqs last  enabled at (186566): [<c01023a0>]
__do_softirq+0x1f8/0x2a0
[    3.348665] softirqs last disabled at (186577): [<c012bffc>]
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:
[    3.391662]   #0: mx6ul-wm8960
[    3.536866] EXT4-fs (mmcblk1p2): recovery complete
[    3.545725] EXT4-fs (mmcblk1p2): mounted filesystem with ordered
data mode. Opts: (null)
[    3.554300] VFS: Mounted root (ext4 filesystem) on device 179:2.
[    3.587857] devtmpfs: mounted
[    3.600044] Freeing unused kernel memory: 1024K
[    3.775667] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null)
Starting logging: OK
Initializing random number generator... done.
Starting network: OK

Welcome to Buildroot

It would be nice to fix this cfg80211 certificate issue though. My
colleague Breno has observed this same issue on a imx7.

Thanks

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 <festevam@gmail.com> wrote:
> Hi Martin,
>
> On Tue, Apr 10, 2018 at 2:06 PM, Martin Townsend
> <mtownsend1973@gmail.com> wrote:
>> Hi Fabio,
>>
>> On Tue, Apr 10, 2018 at 5:59 PM, Fabio Estevam <festevam@gmail.com> wrote:
>>> Hi Martin,
>>>
>>> On Mon, Apr 9, 2018 at 5:41 AM, Martin Townsend <mtownsend1973@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: 40000789: 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-00002-gf0ccf31-dirty #223
> [    3.050413] Hardware name: Freescale i.MX6 Ultralite (Device Tree)
> [    3.056643] Backtrace:
> [    3.059173] [<c010d118>] (dump_backtrace) from [<c010d3d8>]
> (show_stack+0x18/0x1c)
> [    3.066802]  r7:00000000 r6:60000153 r5:00000000 r4:c107ae78
> [    3.072523] [<c010d3c0>] (show_stack) from [<c0a50d24>]
> (dump_stack+0xb4/0xe8)
> [    3.079810] [<c0a50c70>] (dump_stack) from [<c012618c>] (__warn+0x104/0x130)
> [    3.086922]  r9:d604dc94 r8:00000094 r7:00000009 r6:c0d3aea8
> r5:00000000 r4:00000000
> [    3.094728] [<c0126088>] (__warn) from [<c01262d0>]
> (warn_slowpath_null+0x44/0x50)
> [    3.102356]  r8:c1008908 r7:d67846c0 r6:c040bbc4 r5:00000094 r4:c0d3aea8
> [    3.109120] [<c012628c>] (warn_slowpath_null) from [<c040bbc4>]
> (public_key_verify_signature+0x27c/0x2b0)
> [    3.118745]  r6:40000789 r5:d6782f00 r4:d6787f40
> [    3.123428] [<c040b948>] (public_key_verify_signature) from
> [<c040cbd4>] (x509_check_for_self_signed+0xc8/0x104)
> [    3.133664]  r10:d602f000 r9:c0bcb1d0 r8:000002a8 r7:d6787f00
> r6:d6787f40 r5:00000000
> [    3.141543]  r4:d6782d80
> [    3.144140] [<c040cb0c>] (x509_check_for_self_signed) from
> [<c040bdd0>] (x509_cert_parse+0x11c/0x190)
> [    3.153415]  r7:c0bcb1d0 r6:d6787f80 r5:d6782d80 r4:d6787f00
> [    3.159138] [<c040bcb4>] (x509_cert_parse) from [<c040c860>]
> (x509_key_preparse+0x1c/0x194)
> [    3.167550]  r9:c0bcb1d0 r8:c10235dc r7:d604de30 r6:c1026a84
> r5:d604de30 r4:c1026af0
> [    3.175357] [<c040c844>] (x509_key_preparse) from [<c040adbc>]
> (asymmetric_key_preparse+0x50/0x80)
> [    3.184376]  r9:c0bcb1d0 r8:c10235dc r7:d604de30 r6:c1026a84
> r5:c1008908 r4:c1026af0
> [    3.192187] [<c040ad6c>] (asymmetric_key_preparse) from
> [<c03e40b4>] (key_create_or_update+0x138/0x404)
> [    3.201638]  r7:d6495601 r6:d6495600 r5:c1008908 r4:c1026a8c
> [    3.207366] [<c03e3f7c>] (key_create_or_update) from [<c0f5a9c4>]
> (regulatory_init_db+0xf4/0x1e8)
> [    3.216303]  r10:0000000e r9:1f030000 r8:c0d1d144 r7:c17f1e7c
> r6:c0bcb478 r5:000002a8
> [    3.224180]  r4:c0bcb1d0
> [    3.226780] [<c0f5a8d0>] (regulatory_init_db) from [<c0102764>]
> (do_one_initcall+0x50/0x1a4)
> [    3.235278]  r10:c0f00630 r9:c0f64858 r8:c107cb00 r7:00000000
> r6:c0f5a8d0 r5:c1008908
> [    3.243155]  r4:ffffe000
> [    3.245753] [<c0102714>] (do_one_initcall) from [<c0f00f04>]
> (kernel_init_freeable+0x118/0x1d8)
> [    3.254512]  r9:c0f64858 r8:000000f4 r7:c0e1ec98 r6:c0f64854
> r5:c107cb00 r4:c0f78f70
> [    3.262324] [<c0f00dec>] (kernel_init_freeable) from [<c0a665b8>]
> (kernel_init+0x10/0x118)
> [    3.270650]  r10:00000000 r9:00000000 r8:00000000 r7:00000000
> r6:00000000 r5:c0a665a8
> [    3.278527]  r4:00000000
> [    3.281127] [<c0a665a8>] (kernel_init) from [<c01010b4>]
> (ret_from_fork+0x14/0x20)
> [    3.288749] Exception stack(0xd604dfb0 to 0xd604dff8)
> [    3.293859] dfa0:                                     00000000
> 00000000 00000000 00000000
> [    3.302098] dfc0: 00000000 00000000 00000000 00000000 00000000
> 00000000 00000000 00000000
> [    3.310329] dfe0: 00000000 00000000 00000000 00000000 00000013 00000000
> [    3.316993]  r5:c0a665a8 r4:00000000
> [    3.320825] irq event stamp: 186525
> [    3.324504] hardirqs last  enabled at (186543): [<c01803b8>]
> console_unlock+0x4d4/0x5c8
> [    3.332584] hardirqs last disabled at (186550): [<c017ffac>]
> console_unlock+0xc8/0x5c8
> [    3.340664] softirqs last  enabled at (186566): [<c01023a0>]
> __do_softirq+0x1f8/0x2a0
> [    3.348665] softirqs last disabled at (186577): [<c012bffc>]
> 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:
> [    3.391662]   #0: mx6ul-wm8960
> [    3.536866] EXT4-fs (mmcblk1p2): recovery complete
> [    3.545725] EXT4-fs (mmcblk1p2): mounted filesystem with ordered
> data mode. Opts: (null)
> [    3.554300] VFS: Mounted root (ext4 filesystem) on device 179:2.
> [    3.587857] devtmpfs: mounted
> [    3.600044] Freeing unused kernel memory: 1024K
> [    3.775667] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null)
> Starting logging: OK
> Initializing random number generator... done.
> Starting network: OK
>
> Welcome to Buildroot
>
> It would be nice to fix this cfg80211 certificate issue though. My
> colleague Breno has observed this same issue on a imx7.
>
> Thanks

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

signature00000000: 00 68 82 cc 5d f9 ee fb 1a 77 72 a6 a9 c6 4c cc
.h..]....wr...L.
signature00000010: d7 f6 2a 17 a5 db bf 5a 2b 8d 39 60 dc a0 93 39
..*....Z+.9`...9
signature00000020: 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: 40000789: 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-00002-gf0ccf31-dirty #223
>> [    3.050413] Hardware name: Freescale i.MX6 Ultralite (Device Tree)
>> [    3.056643] Backtrace:
>> [    3.059173] [<c010d118>] (dump_backtrace) from [<c010d3d8>]
>> (show_stack+0x18/0x1c)
>> [    3.066802]  r7:00000000 r6:60000153 r5:00000000 r4:c107ae78
>> [    3.072523] [<c010d3c0>] (show_stack) from [<c0a50d24>]
>> (dump_stack+0xb4/0xe8)
>> [    3.079810] [<c0a50c70>] (dump_stack) from [<c012618c>] (__warn+0x104/0x130)
>> [    3.086922]  r9:d604dc94 r8:00000094 r7:00000009 r6:c0d3aea8
>> r5:00000000 r4:00000000
>> [    3.094728] [<c0126088>] (__warn) from [<c01262d0>]
>> (warn_slowpath_null+0x44/0x50)
>> [    3.102356]  r8:c1008908 r7:d67846c0 r6:c040bbc4 r5:00000094 r4:c0d3aea8
>> [    3.109120] [<c012628c>] (warn_slowpath_null) from [<c040bbc4>]
>> (public_key_verify_signature+0x27c/0x2b0)
>> [    3.118745]  r6:40000789 r5:d6782f00 r4:d6787f40
>> [    3.123428] [<c040b948>] (public_key_verify_signature) from
>> [<c040cbd4>] (x509_check_for_self_signed+0xc8/0x104)
>> [    3.133664]  r10:d602f000 r9:c0bcb1d0 r8:000002a8 r7:d6787f00
>> r6:d6787f40 r5:00000000
>> [    3.141543]  r4:d6782d80
>> [    3.144140] [<c040cb0c>] (x509_check_for_self_signed) from
>> [<c040bdd0>] (x509_cert_parse+0x11c/0x190)
>> [    3.153415]  r7:c0bcb1d0 r6:d6787f80 r5:d6782d80 r4:d6787f00
>> [    3.159138] [<c040bcb4>] (x509_cert_parse) from [<c040c860>]
>> (x509_key_preparse+0x1c/0x194)
>> [    3.167550]  r9:c0bcb1d0 r8:c10235dc r7:d604de30 r6:c1026a84
>> r5:d604de30 r4:c1026af0
>> [    3.175357] [<c040c844>] (x509_key_preparse) from [<c040adbc>]
>> (asymmetric_key_preparse+0x50/0x80)
>> [    3.184376]  r9:c0bcb1d0 r8:c10235dc r7:d604de30 r6:c1026a84
>> r5:c1008908 r4:c1026af0
>> [    3.192187] [<c040ad6c>] (asymmetric_key_preparse) from
>> [<c03e40b4>] (key_create_or_update+0x138/0x404)
>> [    3.201638]  r7:d6495601 r6:d6495600 r5:c1008908 r4:c1026a8c
>> [    3.207366] [<c03e3f7c>] (key_create_or_update) from [<c0f5a9c4>]
>> (regulatory_init_db+0xf4/0x1e8)
>> [    3.216303]  r10:0000000e r9:1f030000 r8:c0d1d144 r7:c17f1e7c
>> r6:c0bcb478 r5:000002a8
>> [    3.224180]  r4:c0bcb1d0
>> [    3.226780] [<c0f5a8d0>] (regulatory_init_db) from [<c0102764>]
>> (do_one_initcall+0x50/0x1a4)
>> [    3.235278]  r10:c0f00630 r9:c0f64858 r8:c107cb00 r7:00000000
>> r6:c0f5a8d0 r5:c1008908
>> [    3.243155]  r4:ffffe000
>> [    3.245753] [<c0102714>] (do_one_initcall) from [<c0f00f04>]
>> (kernel_init_freeable+0x118/0x1d8)
>> [    3.254512]  r9:c0f64858 r8:000000f4 r7:c0e1ec98 r6:c0f64854
>> r5:c107cb00 r4:c0f78f70
>> [    3.262324] [<c0f00dec>] (kernel_init_freeable) from [<c0a665b8>]
>> (kernel_init+0x10/0x118)
>> [    3.270650]  r10:00000000 r9:00000000 r8:00000000 r7:00000000
>> r6:00000000 r5:c0a665a8
>> [    3.278527]  r4:00000000
>> [    3.281127] [<c0a665a8>] (kernel_init) from [<c01010b4>]
>> (ret_from_fork+0x14/0x20)
>> [    3.288749] Exception stack(0xd604dfb0 to 0xd604dff8)
>> [    3.293859] dfa0:                                     00000000
>> 00000000 00000000 00000000
>> [    3.302098] dfc0: 00000000 00000000 00000000 00000000 00000000
>> 00000000 00000000 00000000
>> [    3.310329] dfe0: 00000000 00000000 00000000 00000000 00000013 00000000
>> [    3.316993]  r5:c0a665a8 r4:00000000
>> [    3.320825] irq event stamp: 186525
>> [    3.324504] hardirqs last  enabled at (186543): [<c01803b8>]
>> console_unlock+0x4d4/0x5c8
>> [    3.332584] hardirqs last disabled at (186550): [<c017ffac>]
>> console_unlock+0xc8/0x5c8
>> [    3.340664] softirqs last  enabled at (186566): [<c01023a0>]
>> __do_softirq+0x1f8/0x2a0
>> [    3.348665] softirqs last disabled at (186577): [<c012bffc>]
>> 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:
>> [    3.391662]   #0: mx6ul-wm8960
>> [    3.536866] EXT4-fs (mmcblk1p2): recovery complete
>> [    3.545725] EXT4-fs (mmcblk1p2): mounted filesystem with ordered
>> data mode. Opts: (null)
>> [    3.554300] VFS: Mounted root (ext4 filesystem) on device 179:2.
>> [    3.587857] devtmpfs: mounted
>> [    3.600044] Freeing unused kernel memory: 1024K
>> [    3.775667] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null)
>> Starting logging: OK
>> Initializing random number generator... done.
>> Starting network: OK
>>
>> Welcome to Buildroot
>>
>> It would be nice to fix this cfg80211 certificate issue though. My
>> colleague Breno has observed this same issue on a imx7.
>>
>> Thanks

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

[Horia Geantă]

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

[Martin Townsend]

On Wed, Apr 11, 2018 at 11:58 AM, Horia Geanta <horia.geanta@nxp.com> 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

[Martin Townsend]

Hi James,

On Tue, Apr 10, 2018 at 11:36 PM, James Bottomley
<James.Bottomley@hansenpartnership.com> 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

[Fabio Estevam]

Hi Martin,

On Tue, Apr 10, 2018 at 7:01 PM, Martin Townsend
<mtownsend1973@gmail.com> 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] signature00000000: 00 87 03 da f2 82 c2 dd af 7c 44 2f
86 d3 5f 4c  .........|D/.._L
[    3.008213] signature00000010: 93 48 b9 fe 07 17 bb 21 f7 25 23 4e
aa 22 0c 16  .H.....!.%#N."..
[    3.017069] signature00000020: b9 73 ae 9d 46 7c 75 d9 c3 49 57 47
bf 33 b7 97  .s..F|u..IWG.3..
[    3.026064] signature00000030: ec f5 40 75 c0 46 22 f0 a0 5d 9c 79
13 a1 ff b8  ..@u.F"..].y....
[    3.035049] signature00000040: a3 2f 7b 8e 06 3f c8 b6 e4 6a 28 f2
34 5c 23 3f  ./{..?...j(.4\#?
[    3.043994] signature00000050: 32 c0 e6 ad 0f ac cf 55 74 47 73 d3
01 85 b7 0b  2......UtGs.....
[    3.052941] signature00000060: 22 56 24 7d 9f 09 a9 0e 86 9e 37 5b
9c 6d 02 d9  "V$}......7[.m..
[    3.061879] signature00000070: 8c c8 50 6a e2 59 f3 16 06 ea b2 42
b5 58 fe ba  ..Pj.Y.....B.X..
[    3.070813] signature00000080: d1 81 57 1a ef b2 38 88 58 f6 aa c4
2e 8b 5a 27  ..W...8.X.....Z'
[    3.079742] signature00000090: e4 a5 e8 a4 ca 67 5c ac 72 67 c3 6f
13 c3 2d 35  .....g\.rg.o..-5
[    3.088669] signature000000a0: 79 d7 8a e7 f5 d4 21 30 4a d5 f6 a3
d9 79 56 f2  y.....!0J....yV.
[    3.097512] signature000000b0: 0f 10 f7 7d d0 51 93 2f 47 f8 7d 4b
0a 84 55 12  ...}.Q./G.}K..U.
[    3.106437] signature000000c0: 0a 7d 4e 3b 1f 2b 2f fc 28 b3 69 34
e1 80 80 bb  .}N;.+/.(.i4....
[    3.115366] signature000000d0: e2 af b9 d6 30 f1 1d 54 87 23 99 9f
51 03 4c 45  ....0..T.#..Q.LE
[    3.124292] signature000000e0: 7d 02 65 73 ab fd cf 94 cc 0d 3a 60
fd 3c 14 2f  }.es......:`.<./
[    3.133238] signature000000f0: 16 33 a9 21 1f cb 50 b1 8f 03 ee a0
66 a9 16 79  .3.!..P.....f..y
[    3.142189] signature00000100: 14
            .
[    3.155013] caam_jr 2142000.jr1: 40000789: 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] signature00000000: 00 87 03 da f2 82 c2 dd af 7c 44 2f
86 d3 5f 4c  .........|D/.._L
[    2.671221] signature00000010: 93 48 b9 fe 07 17 bb 21 f7 25 23 4e
aa 22 0c 16  .H.....!.%#N."..
[    2.680082] signature00000020: b9 73 ae 9d 46 7c 75 d9 c3 49 57 47
bf 33 b7 97  .s..F|u..IWG.3..
[    2.688893] signature00000030: ec f5 40 75 c0 46 22 f0 a0 5d 9c 79
13 a1 ff b8  ..@u.F"..].y....
[    2.697750] signature00000040: a3 2f 7b 8e 06 3f c8 b6 e4 6a 28 f2
34 5c 23 3f  ./{..?...j(.4\#?
[    2.706604] signature00000050: 32 c0 e6 ad 0f ac cf 55 74 47 73 d3
01 85 b7 0b  2......UtGs.....
[    2.715460] signature00000060: 22 56 24 7d 9f 09 a9 0e 86 9e 37 5b
9c 6d 02 d9  "V$}......7[.m..
[    2.724323] signature00000070: 8c c8 50 6a e2 59 f3 16 06 ea b2 42
b5 58 fe ba  ..Pj.Y.....B.X..
[    2.733182] signature00000080: d1 81 57 1a ef b2 38 88 58 f6 aa c4
2e 8b 5a 27  ..W...8.X.....Z'
[    2.742032] signature00000090: e4 a5 e8 a4 ca 67 5c ac 72 67 c3 6f
13 c3 2d 35  .....g\.rg.o..-5
[    2.750883] signature000000a0: 79 d7 8a e7 f5 d4 21 30 4a d5 f6 a3
d9 79 56 f2  y.....!0J....yV.
[    2.759737] signature000000b0: 0f 10 f7 7d d0 51 93 2f 47 f8 7d 4b
0a 84 55 12  ...}.Q./G.}K..U.
[    2.768543] signature000000c0: 0a 7d 4e 3b 1f 2b 2f fc 28 b3 69 34
e1 80 80 bb  .}N;.+/.(.i4....
[    2.777403] signature000000d0: e2 af b9 d6 30 f1 1d 54 87 23 99 9f
51 03 4c 45  ....0..T.#..Q.LE
[    2.786259] signature000000e0: 7d 02 65 73 ab fd cf 94 cc 0d 3a 60
fd 3c 14 2f  }.es......:`.<./
[    2.795110] signature000000f0: 16 33 a9 21 1f cb 50 b1 8f 03 ee a0
66 a9 16 79  .3.!..P.....f..y
[    2.803957] signature00000100: 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

[Horia Geantă]

On 4/11/2018 5:21 AM, Fabio Estevam wrote:
> Hi Martin,
> 
> On Tue, Apr 10, 2018 at 7:01 PM, Martin Townsend
> <mtownsend1973@gmail.com> 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

[Fabio Estevam]

Hi Horia,

On Wed, Apr 11, 2018 at 7:15 AM, Horia Geanta <horia.geanta@nxp.com> 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

[Horia Geantă]

On 4/11/2018 8:26 PM, Fabio Estevam wrote:
> Hi Horia,
> 
> On Wed, Apr 11, 2018 at 7:15 AM, Horia Geanta <horia.geanta@nxp.com> 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

[Fabio Estevam]

Hi Horia,

On Thu, Apr 12, 2018 at 4:12 AM, Horia Geanta <horia.geanta@nxp.com> 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: 40000789: 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-00005-g5e59986-dirty #323
[    3.095726] Hardware name: Freescale i.MX6 Ultralite (Device Tree)
[    3.101954] Backtrace:
[    3.104482] [<c010d118>] (dump_backtrace) from [<c010d3d8>]
(show_stack+0x18/0x1c)
[    3.112113]  r7:00000000 r6:60000153 r5:00000000 r4:c107ae78
[    3.117840] [<c010d3c0>] (show_stack) from [<c0a50f24>]
(dump_stack+0xb4/0xe8)
[    3.125126] [<c0a50e70>] (dump_stack) from [<c012618c>] (__warn+0x104/0x130)
[    3.132236]  r9:d804dc94 r8:00000094 r7:00000009 r6:c0d3aed8
r5:00000000 r4:00000000
[    3.140036] [<c0126088>] (__warn) from [<c01262d0>]
(warn_slowpath_null+0x44/0x50)
[    3.147665]  r8:c1008908 r7:d87846c0 r6:c040bbc4 r5:00000094 r4:c0d3aed8
[    3.154428] [<c012628c>] (warn_slowpath_null) from [<c040bbc4>]
(public_key_verify_signature+0x27c/0x2b0)
[    3.164049]  r6:40000789 r5:d8782e00 r4:d8787ec0
[    3.168731] [<c040b948>] (public_key_verify_signature) from
[<c040cbd4>] (x509_check_for_self_signed+0xc8/0x104)
[    3.178963]  r10:d802f000 r9:c0bcb210 r8:000002a8 r7:d8787e80
r6:d8787ec0 r5:00000000
[    3.186839]  r4:d8782c80
[    3.189434] [<c040cb0c>] (x509_check_for_self_signed) from
[<c040bdd0>] (x509_cert_parse+0x11c/0x190)
[    3.198710]  r7:c0bcb210 r6:d8787f00 r5:d8782c80 r4:d8787e80
[    3.204433] [<c040bcb4>] (x509_cert_parse) from [<c040c860>]
(x509_key_preparse+0x1c/0x194)
[    3.212842]  r9:c0bcb210 r8:c10235dc r7:d804de30 r6:c1026a84
r5:d804de30 r4:c1026af0
[    3.220648] [<c040c844>] (x509_key_preparse) from [<c040adbc>]
(asymmetric_key_preparse+0x50/0x80)
[    3.229665]  r9:c0bcb210 r8:c10235dc r7:d804de30 r6:c1026a84
r5:c1008908 r4:c1026af0
[    3.237473] [<c040ad6c>] (asymmetric_key_preparse) from
[<c03e40b4>] (key_create_or_update+0x138/0x404)
[    3.246920]  r7:d8495601 r6:d8495600 r5:c1008908 r4:c1026a8c
[    3.252650] [<c03e3f7c>] (key_create_or_update) from [<c0f5a9c4>]
(regulatory_init_db+0xf4/0x1e8)
[    3.261586]  r10:0000000e r9:1f030000 r8:c0d1d174 r7:c17f1e7c
r6:c0bcb4b8 r5:000002a8
[    3.269465]  r4:c0bcb210
[    3.272067] [<c0f5a8d0>] (regulatory_init_db) from [<c0102764>]
(do_one_initcall+0x50/0x1a4)
[    3.280572]  r10:c0f00630 r9:c0f64858 r8:c107cb00 r7:00000000
r6:c0f5a8d0 r5:c1008908
[    3.288448]  r4:ffffe000
[    3.291047] [<c0102714>] (do_one_initcall) from [<c0f00f04>]
(kernel_init_freeable+0x118/0x1d8)
[    3.299810]  r9:c0f64858 r8:000000f4 r7:c0e1ec80 r6:c0f64854
r5:c107cb00 r4:c0f78f70
[    3.307620] [<c0f00dec>] (kernel_init_freeable) from [<c0a667b8>]
(kernel_init+0x10/0x118)
[    3.315947]  r10:00000000 r9:00000000 r8:00000000 r7:00000000
r6:00000000 r5:c0a667a8
[    3.323826]  r4:00000000
[    3.326423] [<c0a667a8>] (kernel_init) from [<c01010b4>]
(ret_from_fork+0x14/0x20)
[    3.334042] Exception stack(0xd804dfb0 to 0xd804dff8)
[    3.339150] dfa0:                                     00000000
00000000 00000000 00000000
[    3.347389] dfc0: 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000
[    3.355620] dfe0: 00000000 00000000 00000000 00000000 00000013 00000000
[    3.362283]  r5:c0a667a8 r4:00000000
[    3.366061] irq event stamp: 186637
[    3.369710] hardirqs last  enabled at (186647): [<c01803b8>]
console_unlock+0x4d4/0x5c8
[    3.377877] hardirqs last disabled at (186656): [<c017ffac>]
console_unlock+0xc8/0x5c8
[    3.385867] softirqs last  enabled at (186588): [<c01023a0>]
__do_softirq+0x1f8/0x2a0
[    3.393847] softirqs last disabled at (186525): [<c012bffc>]
irq_exit+0x14c/0x1a8
[    3.401470] ---[ end trace 6e7c53a2c467c87b ]---
[    3.406196] cfg80211: Problem loading in-kernel X.509 certificate (-22)
[    3.416311] platform regulatory.0: Direct firmware load for
regulatory.db failed with error -2
[    3.425458] cfg80211: failed to load regulatory.db

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

[Horia Geantă]

On 4/13/2018 3:12 AM, Fabio Estevam wrote:
> Hi Horia,
> 
> On Thu, Apr 12, 2018 at 4:12 AM, Horia Geanta <horia.geanta@nxp.com> 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

[Fabio Estevam]

Hi Horia,

On Fri, Apr 13, 2018 at 3:18 AM, Horia Geanta <horia.geanta@nxp.com> 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