All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Walle <michael@walle.cc>
To: a.fatoum@pengutronix.de
Cc: davem@davemloft.net, david@sigma-star.at, dhowells@redhat.com,
	ebiggers@kernel.org, franck.lenormand@nxp.com,
	herbert@gondor.apana.org.au, horia.geanta@nxp.com,
	j.luebbe@pengutronix.de, jarkko@kernel.org, jejb@linux.ibm.com,
	jmorris@namei.org, kernel@pengutronix.de,
	keyrings@vger.kernel.org, linux-crypto@vger.kernel.org,
	linux-integrity@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-security-module@vger.kernel.org,
	matthias.schiffer@ew.tq-group.com, pankaj.gupta@nxp.com,
	richard@nod.at, serge@hallyn.com, sumit.garg@linaro.org,
	tharvey@gateworks.com, zohar@linux.ibm.com,
	Michael Walle <michael@walle.cc>
Subject: Re: [PATCH v8 3/6] crypto: caam - add in-kernel interface for blob generator
Date: Tue,  3 May 2022 20:24:54 +0200	[thread overview]
Message-ID: <20220503182454.2749454-1-michael@walle.cc> (raw)
In-Reply-To: <20220428140145.870527-4-a.fatoum@pengutronix.de>

Hi,

> The NXP Cryptographic Acceleration and Assurance Module (CAAM)
> can be used to protect user-defined data across system reboot:
> 
>   - When the system is fused and boots into secure state, the master
>     key is a unique never-disclosed device-specific key
>   - random key is encrypted by key derived from master key
>   - data is encrypted using the random key
>   - encrypted data and its encrypted random key are stored alongside
>   - This blob can now be safely stored in non-volatile memory
> 
> On next power-on:
>   - blob is loaded into CAAM
>   - CAAM writes decrypted data either into memory or key register
> 
> Add functions to realize encrypting and decrypting into memory alongside
> the CAAM driver.
> 
> They will be used in a later commit as a source for the trusted key
> seal/unseal mechanism.

Thanks for the work on this and I'm excited to try this. I'm currently
playing with this and one thing I've noticed is that an export restricted
CAAM isn't handled properly.

That is, there are CAAM's which aren't fully featured. Normally, the
caam driver will take care of it. For example, see commit f20311cc9c58
("crypto: caam - disable pkc for non-E SoCs"). For the trusted keys case,
it would be nice if the kernel will not even probe (or similar).

Right now, everything seems to work fine, but once I try to add a new key,
I'll get the following errros:

# keyctl add trusted mykey "new 32" @u
add_key: Invalid argument
[   23.138714] caam_jr 8020000.jr: 20000b0f: CCB: desc idx 11: : Invalid CHA selected.
[   23.138740] trusted_key: key_seal failed (-22)

Again this is expected, because I run it on a non-E version. IMHO, it
should be that the trusted keys shouldn't be enabled at all. Like it is
for example if an unknown rng is given:

  trusted_key: Unsupported RNG. Supported: kernel, default

Thanks,
-michael

  reply	other threads:[~2022-05-03 18:25 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-28 14:21 [PATCH v8 0/6] KEYS: trusted: Introduce support for NXP CAAM-based trusted keys Ahmad Fatoum
2022-04-28 14:01 ` [PATCH v8 1/6] KEYS: trusted: allow use of TEE as backend without TCG_TPM support Ahmad Fatoum
2022-04-28 14:01 ` [PATCH v8 2/6] KEYS: trusted: allow use of kernel RNG for key material Ahmad Fatoum
2022-04-28 14:01 ` [PATCH v8 3/6] crypto: caam - add in-kernel interface for blob generator Ahmad Fatoum
2022-05-03 18:24   ` Michael Walle [this message]
2022-05-04  6:39     ` Ahmad Fatoum
2022-04-28 14:01 ` [PATCH v8 4/6] KEYS: trusted: Introduce support for NXP CAAM-based trusted keys Ahmad Fatoum
2022-04-28 14:01 ` [PATCH v8 5/6] doc: trusted-encrypted: describe new CAAM trust source Ahmad Fatoum
2022-05-04  4:15   ` Jarkko Sakkinen
2022-04-28 14:01 ` [PATCH v8 6/6] MAINTAINERS: add myself as CAAM trusted key maintainer Ahmad Fatoum
2022-05-04  4:24   ` Jarkko Sakkinen
2022-05-04  4:57     ` Ahmad Fatoum
2022-05-05 14:58 ` [PATCH v8 0/6] KEYS: trusted: Introduce support for NXP CAAM-based trusted keys John Ernberg
2022-05-05 17:33   ` Ahmad Fatoum
2022-05-07 21:30     ` John Ernberg
2022-05-11 10:44       ` Ahmad Fatoum

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220503182454.2749454-1-michael@walle.cc \
    --to=michael@walle.cc \
    --cc=a.fatoum@pengutronix.de \
    --cc=davem@davemloft.net \
    --cc=david@sigma-star.at \
    --cc=dhowells@redhat.com \
    --cc=ebiggers@kernel.org \
    --cc=franck.lenormand@nxp.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=horia.geanta@nxp.com \
    --cc=j.luebbe@pengutronix.de \
    --cc=jarkko@kernel.org \
    --cc=jejb@linux.ibm.com \
    --cc=jmorris@namei.org \
    --cc=kernel@pengutronix.de \
    --cc=keyrings@vger.kernel.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=matthias.schiffer@ew.tq-group.com \
    --cc=pankaj.gupta@nxp.com \
    --cc=richard@nod.at \
    --cc=serge@hallyn.com \
    --cc=sumit.garg@linaro.org \
    --cc=tharvey@gateworks.com \
    --cc=zohar@linux.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.