[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <CZLC14YSOYS5.XWHWWQYZCFZ3@suppilovahvero>
Date: Tue, 05 Mar 2024 00:51:33 +0200
From: "Jarkko Sakkinen" <jarkko@...nel.org>
To: "Paul Moore" <paul@...l-moore.com>, "David Gstir" <david@...ma-star.at>,
"Mimi Zohar" <zohar@...ux.ibm.com>, "David Howells" <dhowells@...hat.com>
Cc: "James Bottomley" <jejb@...ux.ibm.com>, "Herbert Xu"
<herbert@...dor.apana.org.au>, "David S. Miller" <davem@...emloft.net>,
"Shawn Guo" <shawnguo@...nel.org>, "Jonathan Corbet" <corbet@....net>,
"Sascha Hauer" <s.hauer@...gutronix.de>, "Pengutronix Kernel Team"
<kernel@...gutronix.de>, "Fabio Estevam" <festevam@...il.com>, "NXP Linux
Team" <linux-imx@....com>, "Ahmad Fatoum" <a.fatoum@...gutronix.de>, "sigma
star Kernel Team" <upstream+dcp@...ma-star.at>, "Li Yang"
<leoyang.li@....com>, "James Morris" <jmorris@...ei.org>, "Serge E. Hallyn"
<serge@...lyn.com>, "Paul E. McKenney" <paulmck@...nel.org>, "Randy Dunlap"
<rdunlap@...radead.org>, "Catalin Marinas" <catalin.marinas@....com>,
"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>, "Tejun Heo"
<tj@...nel.org>, "Steven Rostedt (Google)" <rostedt@...dmis.org>,
<linux-doc@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
<linux-integrity@...r.kernel.org>, <keyrings@...r.kernel.org>,
<linux-crypto@...r.kernel.org>, <linux-arm-kernel@...ts.infradead.org>,
<linuxppc-dev@...ts.ozlabs.org>, <linux-security-module@...r.kernel.org>
Subject: Re: [PATCH v5 0/6] DCP as trusted keys backend
On Tue Dec 19, 2023 at 2:45 AM EET, Paul Moore wrote:
> On Fri, Dec 15, 2023 at 6:07 AM David Gstir <david@...ma-star.at> wrote:
> >
> > This is a revival of the previous patch set submitted by Richard Weinberger:
> > https://lore.kernel.org/linux-integrity/20210614201620.30451-1-richard@nod.at/
> >
> > v4 is here:
> > https://lore.kernel.org/keyrings/20231024162024.51260-1-david@sigma-star.at/
> >
> > v4 -> v5:
> > - Make Kconfig for trust source check scalable as suggested by Jarkko Sakkinen
> > - Add Acked-By from Herbert Xu to patch #1 - thanks!
> > v3 -> v4:
> > - Split changes on MAINTAINERS and documentation into dedicated patches
> > - Use more concise wording in commit messages as suggested by Jarkko Sakkinen
> > v2 -> v3:
> > - Addressed review comments from Jarkko Sakkinen
> > v1 -> v2:
> > - Revive and rebase to latest version
> > - Include review comments from Ahmad Fatoum
> >
> > The Data CoProcessor (DCP) is an IP core built into many NXP SoCs such
> > as i.mx6ull.
> >
> > Similar to the CAAM engine used in more powerful SoCs, DCP can AES-
> > encrypt/decrypt user data using a unique, never-disclosed,
> > device-specific key. Unlike CAAM though, it cannot directly wrap and
> > unwrap blobs in hardware. As DCP offers only the bare minimum feature
> > set and a blob mechanism needs aid from software. A blob in this case
> > is a piece of sensitive data (e.g. a key) that is encrypted and
> > authenticated using the device-specific key so that unwrapping can only
> > be done on the hardware where the blob was wrapped.
> >
> > This patch series adds a DCP based, trusted-key backend and is similar
> > in spirit to the one by Ahmad Fatoum [0] that does the same for CAAM.
> > It is of interest for similar use cases as the CAAM patch set, but for
> > lower end devices, where CAAM is not available.
> >
> > Because constructing and parsing the blob has to happen in software,
> > we needed to decide on a blob format and chose the following:
> >
> > struct dcp_blob_fmt {
> > __u8 fmt_version;
> > __u8 blob_key[AES_KEYSIZE_128];
> > __u8 nonce[AES_KEYSIZE_128];
> > __le32 payload_len;
> > __u8 payload[];
> > } __packed;
> >
> > The `fmt_version` is currently 1.
> >
> > The encrypted key is stored in the payload area. It is AES-128-GCM
> > encrypted using `blob_key` and `nonce`, GCM auth tag is attached at
> > the end of the payload (`payload_len` does not include the size of
> > the auth tag).
> >
> > The `blob_key` itself is encrypted in AES-128-ECB mode by DCP using
> > the OTP or UNIQUE device key. A new `blob_key` and `nonce` are generated
> > randomly, when sealing/exporting the DCP blob.
> >
> > This patchset was tested with dm-crypt on an i.MX6ULL board.
> >
> > [0] https://lore.kernel.org/keyrings/20220513145705.2080323-1-a.fatoum@pengutronix.de/
> >
> > David Gstir (6):
> > crypto: mxs-dcp: Add support for hardware-bound keys
> > KEYS: trusted: improve scalability of trust source config
> > KEYS: trusted: Introduce NXP DCP-backed trusted keys
> > MAINTAINERS: add entry for DCP-based trusted keys
> > docs: document DCP-backed trusted keys kernel params
> > docs: trusted-encrypted: add DCP as new trust source
> >
> > .../admin-guide/kernel-parameters.txt | 13 +
> > .../security/keys/trusted-encrypted.rst | 85 +++++
> > MAINTAINERS | 9 +
> > drivers/crypto/mxs-dcp.c | 104 +++++-
> > include/keys/trusted_dcp.h | 11 +
> > include/soc/fsl/dcp.h | 17 +
> > security/keys/trusted-keys/Kconfig | 18 +-
> > security/keys/trusted-keys/Makefile | 2 +
> > security/keys/trusted-keys/trusted_core.c | 6 +-
> > security/keys/trusted-keys/trusted_dcp.c | 311 ++++++++++++++++++
> > 10 files changed, 562 insertions(+), 14 deletions(-)
> > create mode 100644 include/keys/trusted_dcp.h
> > create mode 100644 include/soc/fsl/dcp.h
> > create mode 100644 security/keys/trusted-keys/trusted_dcp.c
>
> Jarkko, Mimi, David - if this patchset isn't already in your review
> queue, can you take a look at it from a security/keys perspective?
>
> Thanks.
I gave my 5 cents. I had no intention not to review it, somehow just
slipped. I try to do my best but sometimes this still does happen :-) So
please ping me if there is radio silence.
BR, Jarkko
Powered by blists - more mailing lists