Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
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
Message-Id: <20220503182454.2749454-1-michael@walle.cc>
In-Reply-To: <20220428140145.870527-4-a.fatoum@pengutronix.de>
References: <20220428140145.870527-4-a.fatoum@pengutronix.de>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Precedence: bulk

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