Received: by 2002:a05:6a10:c604:0:0:0:0 with SMTP id y4csp3572116pxt; Tue, 10 Aug 2021 06:40:29 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx8bZdOt+u5Yyk0028CYt9ptekfcBagp/r2FYm/c+0BE+gaIoBezDEomI0dEtZkBvNsOTJn X-Received: by 2002:a6b:5d18:: with SMTP id r24mr577532iob.156.1628602829006; Tue, 10 Aug 2021 06:40:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1628602828; cv=none; d=google.com; s=arc-20160816; b=lzxQJ3TfVpK8+21+eKltHZpmtN8xS9mxKI/0nOsp1ANHCnTlv/M1MgbwgZz6hqO9hU rzZAMIJUU4OvzxqrSnb4HJDQBZPdqUOIeYf96DyaHlgJrpbnE9OmK1de+VCBsrdGaUO1 9V/wgRUYvNSm5qbysVnzNHtNGsZAFrRgVtbWWraK+kDOh3TNxmmo6PL+aDhkqaDgtvMz 6yfLO3iM1JY36gp4+ZvVBTcETbwy91wWBr+QmVvKCnLcBv+J+LEFM/Ka08Y3FsA+p6zr 3a74Zn6srf6/ZOO1BXWR0Xdb894CGqnIe26Kj7/YShgcetpYXyxCk2j9VLy2PsLWvY/t EV1w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:reply-to:cc:from:to:date; bh=p9WDT2whXO9aPucssbA6mqLrO6oMrfxO5X7L48yMK9w=; b=JMr7Z08iBljwzpEToUpG48NzzF4ZVs26qwdVizxv6lF5O/JmNAXLHw3qVzQxegYRls /krOrQJ2Y583Id+zKKbMBwrIpN2b4qJGgYm56sv8m4/WvjQgWrE412HPrSg5X1sZQc9r b2bf9C5HVf75sJJ3pRugNFsOBoliBh6YBez2oK6O4BlPCihUDrgGtCO7stix7PBVb0uR IAGMKMEhsbC/1xTltnJAgJ8cTUP9yJPbIIgnBSG0d6KAzemQXhSgiHiLkFQvCFkaHXbx AkOqD0uxLIPzY9qfMU2l/+185z1cx3PqbZoOhhWZfisDpNhZ8Z9P5dNRJcjbrOLsNmFd NgXQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id q16si1508894ioj.19.2021.08.10.06.40.17; Tue, 10 Aug 2021 06:40:28 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238297AbhHJL3e convert rfc822-to-8bit (ORCPT + 99 others); Tue, 10 Aug 2021 07:29:34 -0400 Received: from mail-40133.protonmail.ch ([185.70.40.133]:35203 "EHLO mail-40133.protonmail.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229967AbhHJL3e (ORCPT ); Tue, 10 Aug 2021 07:29:34 -0400 Date: Tue, 10 Aug 2021 11:29:04 +0000 Authentication-Results: mail-40131.protonmail.ch; dkim=none To: Ahmad Fatoum From: David Gstir Cc: =?utf-8?Q?Horia_Geant=C4=83?= , Aymen Sghaier , Herbert Xu , "David S. Miller" , kernel@pengutronix.de, James Bottomley , Jarkko Sakkinen , Mimi Zohar , David Howells , James Morris , Eric Biggers , "Serge E. Hallyn" , Udit Agarwal , Jan Luebbe , Richard Weinberger , Franck LENORMAND , Sumit Garg , 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 Reply-To: David Gstir Subject: Re: [PATCH 3/4] crypto: caam - add in-kernel interface for blob generator Message-ID: <796E18E6-1329-40D6-B12F-4CE6C90DD988@sigma-star.at> In-Reply-To: <4078060ab2e44114af8204b4defea4f3d4b9e285.1626885907.git-series.a.fatoum@pengutronix.de> References: <4078060ab2e44114af8204b4defea4f3d4b9e285.1626885907.git-series.a.fatoum@pengutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT X-Spam-Status: No, score=-1.0 required=10.0 tests=ALL_TRUSTED shortcircuit=no autolearn=disabled version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mailout.protonmail.ch Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org Hi Ahmad, > On 21.07.2021, at 18:48, Ahmad Fatoum wrote: [...] > diff --git a/drivers/crypto/caam/blob_gen.c b/drivers/crypto/caam/blob_gen.c > new file mode 100644 > index 000000000000..513d3f90e438 > --- /dev/null > +++ b/drivers/crypto/caam/blob_gen.c > @@ -0,0 +1,230 @@ [...] > + > +int caam_encap_blob(struct caam_blob_priv *priv, const char *keymod, > + void *input, void *output, size_t length) > +{ > + u32 *desc; > + struct device *jrdev = &priv->jrdev; > + dma_addr_t dma_in, dma_out; > + struct caam_blob_job_result testres; > + size_t keymod_len = strlen(keymod); > + int ret; > + > + if (length <= CAAM_BLOB_OVERHEAD || keymod_len > CAAM_BLOB_KEYMOD_LENGTH) The docs for this function mention the length <= CAAM_BLOB_MAX_LEN restriction. This is not checked here. Is this intended? Since you already assert that MAX_BLOB_SIZE <= CAAM_BLOB_MAX_LEN in security/keys/trusted-keys/trusted_caam.c, this will never be an issue for CAAM-based trusted-keys though. > + return -EINVAL; > + > + desc = caam_blob_alloc_desc(keymod_len); > + if (!desc) { > + dev_err(jrdev, "unable to allocate desc\n"); > + return -ENOMEM; > + } > + [...] > diff --git a/include/soc/fsl/caam-blob.h b/include/soc/fsl/caam-blob.h > new file mode 100644 > index 000000000000..aebbc9335f64 > --- /dev/null > +++ b/include/soc/fsl/caam-blob.h > @@ -0,0 +1,56 @@ > +/* SPDX-License-Identifier: GPL-2.0-only */ > +/* > + * Copyright (C) 2020 Pengutronix, Ahmad Fatoum > + */ > + > +#ifndef __CAAM_BLOB_GEN > +#define __CAAM_BLOB_GEN > + > +#include > + > +#define CAAM_BLOB_KEYMOD_LENGTH 16 > +#define CAAM_BLOB_OVERHEAD (32 + 16) > +#define CAAM_BLOB_MAX_LEN 4096 > + > +struct caam_blob_priv; > + > +/** caam_blob_gen_init - initialize blob generation > + * > + * returns either pointer to new caam_blob_priv instance > + * or error pointer > + */ > +struct caam_blob_priv *caam_blob_gen_init(void); > + > +/** caam_blob_gen_init - free blob generation resources s/init/exit/ > + * > + * @priv: instance returned by caam_blob_gen_init > + */ > +void caam_blob_gen_exit(struct caam_blob_priv *priv); Except these minor things, I noticed no issues with this whole series: Reviewed-by: David Gstir