From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 456F3C433EF for ; Fri, 6 May 2022 10:52:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344999AbiEFK4I (ORCPT ); Fri, 6 May 2022 06:56:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56030 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231966AbiEFK4E (ORCPT ); Fri, 6 May 2022 06:56:04 -0400 Received: from ssl.serverraum.org (ssl.serverraum.org [IPv6:2a01:4f8:151:8464::1:2]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 36CF65C362; Fri, 6 May 2022 03:52:19 -0700 (PDT) Received: from ssl.serverraum.org (web.serverraum.org [172.16.0.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ssl.serverraum.org (Postfix) with ESMTPSA id EE63522246; Fri, 6 May 2022 12:52:13 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walle.cc; s=mail2016061301; t=1651834336; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=hBTLRDXX7HYWGSCeHSGr2YftxW57WhXM3Qvb9yVkUQk=; b=hAWKHoWNoWZfeKBbrvLwwZUOCIaV0Huaxz+PHJqpLVZdnH/5+RDd/z4htrynCe85SCOmNw Jgv/BprTb1DY6+XBz0tjeqOTmMSU13D8llXKPYwvLrHE98OCaqSFNuaY24kEjvMFVy68h1 NH7Id3QryZVY5LUiKPbvxjEB004JDC4= MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 06 May 2022 12:52:13 +0200 From: Michael Walle To: Ahmad Fatoum Cc: Jarkko Sakkinen , =?UTF-8?Q?Horia_Geant=C4=83?= , Mimi Zohar , Pankaj Gupta , Herbert Xu , "David S. Miller" , James Bottomley , kernel@pengutronix.de, David Howells , James Morris , "Serge E. Hallyn" , Steffen Trumtrar , Jan Luebbe , David Gstir , Eric Biggers , Richard Weinberger , Franck LENORMAND , Sumit Garg , Andreas Rammhold , Tim Harvey , Matthias Schiffer , linux-integrity@vger.kernel.org, keyrings@vger.kernel.org, linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org Subject: Re: [PATCH v9 0/7] KEYS: trusted: Introduce support for NXP CAAM-based trusted keys In-Reply-To: <20220506062553.1068296-1-a.fatoum@pengutronix.de> References: <20220506062553.1068296-1-a.fatoum@pengutronix.de> User-Agent: Roundcube Webmail/1.4.13 Message-ID: <49e1738c55c73819ee0e2cac0be74d81@walle.cc> X-Sender: michael@walle.cc Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Am 2022-05-06 08:25, schrieb Ahmad Fatoum: > Series applies on top of v5.18-rc5. Would be great if this could make > it > into v5.19. > > v8 was here: > https://lore.kernel.org/linux-integrity/09e2552c-7392-e1da-926b-53c7db0b118d@pengutronix.de > > Changelog is beneath each individual patch. Compared to v8, only code > change is checking whether CAAM can support blobbing at init-time as > apparently some Layerscape SoCs are available in a non-E(ncryption) > variant that doesn't do AES. Previously, adding trusted keys on such > SoCs would return an error with a cryptic error message. > > > The Cryptographic Acceleration and Assurance Module (CAAM) is an IP > core > built into many newer i.MX and QorIQ SoCs by NXP. > > Its blob mechanism can AES encrypt/decrypt user data using a unique > never-disclosed device-specific key. > > There has been multiple discussions on how to represent this within the > kernel: > > The Cryptographic Acceleration and Assurance Module (CAAM) is an IP > core > built into many newer i.MX and QorIQ SoCs by NXP. > > Its blob mechanism can AES encrypt/decrypt user data using a unique > never-disclosed device-specific key. There has been multiple > discussions on how to represent this within the kernel: > > - [RFC] crypto: caam - add red blobifier > Steffen implemented[1] a PoC sysfs driver to start a discussion on > how to > best integrate the blob mechanism. > Mimi suggested that it could be used to implement trusted keys. > Trusted keys back then were a TPM-only feature. > > - security/keys/secure_key: Adds the secure key support based on CAAM. > Udit Agarwal added[2] a new "secure" key type with the CAAM as > backend. > The key material stays within the kernel only. > Mimi and James agreed that this needs a generic interface, not > specific > to CAAM. Mimi suggested trusted keys. Jan noted that this could > serve as > basis for TEE-backed keys. > > - [RFC] drivers: crypto: caam: key: Add caam_tk key type > Franck added[3] a new "caam_tk" key type based on Udit's work. This > time > it uses CAAM "black blobs" instead of "red blobs", so key material > stays > within the CAAM and isn't exposed to kernel in plaintext. > James voiced the opinion that there should be just one user-facing > generic > wrap/unwrap key type with multiple possible handlers. > David suggested trusted keys. > > - Introduce TEE based Trusted Keys support > Sumit reworked[4] trusted keys to support multiple possible backends > with > one chosen at boot time and added a new TEE backend along with TPM. > This now sits in Jarkko's master branch to be sent out for v5.13 > > This patch series builds on top of Sumit's rework to have the CAAM as > yet another > trusted key backend. > > The CAAM bits are based on Steffen's initial patch from 2015. His work > had been > used in the field for some years now, so I preferred not to deviate > too much from it. > > This series has been tested with dmcrypt[5] on an i.MX6Q/DL and an > i.MX8M[6]. > > Looking forward to your feedback. For the whole series: Tested-by: Michael Walle # on ls1028a (non-E and E) -michael