All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: linux-crypto@vger.kernel.org
Cc: Cheng-Yi Chiang <cychiang@chromium.org>,
	ecryptfs@vger.kernel.org,
	Enric Balletbo i Serra <enric.balletbo@collabora.com>,
	Gilad Ben-Yossef <gilad@benyossef.com>,
	Guenter Roeck <groeck@chromium.org>,
	Jesper Nilsson <jesper.nilsson@axis.com>,
	Kamil Konieczny <k.konieczny@samsung.com>,
	keyrings@vger.kernel.org, Krzysztof Kozlowski <krzk@kernel.org>,
	Krzysztof Opasiak <k.opasiak@samsung.com>,
	Lars Persson <lars.persson@axis.com>,
	linux-bluetooth@vger.kernel.org, linux-mtd@lists.infradead.org,
	linux-nfs@vger.kernel.org, linux-sctp@vger.kernel.org,
	Robert Baldyga <r.baldyga@samsung.com>,
	Tom Lendacky <thomas.lendacky@amd.com>,
	Vladimir Zapolskiy <vz@mleia.com>, Zaibo Xu <xuzaibo@huawei.com>
Subject: [PATCH 01/20] crypto: hash - introduce crypto_shash_tfm_digest()
Date: Fri,  1 May 2020 22:31:03 -0700	[thread overview]
Message-ID: <20200502053122.995648-2-ebiggers@kernel.org> (raw)
In-Reply-To: <20200502053122.995648-1-ebiggers@kernel.org>

From: Eric Biggers <ebiggers@google.com>

Currently the simplest use of the shash API is to use
crypto_shash_digest() to digest a whole buffer.  However, this still
requires allocating a hash descriptor (struct shash_desc).  Many users
don't really want to preallocate one and instead just use a one-off
descriptor on the stack like the following:

	{
		SHASH_DESC_ON_STACK(desc, tfm);
		int err;

		desc->tfm = tfm;

		err = crypto_shash_digest(desc, data, len, out);

		shash_desc_zero(desc);
	}

Wrap this in a new helper function crypto_shash_tfm_digest() that can be
used instead of the above.

Signed-off-by: Eric Biggers <ebiggers@google.com>
---
 crypto/shash.c        | 16 ++++++++++++++++
 include/crypto/hash.h | 19 +++++++++++++++++++
 2 files changed, 35 insertions(+)

diff --git a/crypto/shash.c b/crypto/shash.c
index c075b26c2a1d9f..e6a4b5f39b8c64 100644
--- a/crypto/shash.c
+++ b/crypto/shash.c
@@ -206,6 +206,22 @@ int crypto_shash_digest(struct shash_desc *desc, const u8 *data,
 }
 EXPORT_SYMBOL_GPL(crypto_shash_digest);
 
+int crypto_shash_tfm_digest(struct crypto_shash *tfm, const u8 *data,
+			    unsigned int len, u8 *out)
+{
+	SHASH_DESC_ON_STACK(desc, tfm);
+	int err;
+
+	desc->tfm = tfm;
+
+	err = crypto_shash_digest(desc, data, len, out);
+
+	shash_desc_zero(desc);
+
+	return err;
+}
+EXPORT_SYMBOL_GPL(crypto_shash_tfm_digest);
+
 static int shash_default_export(struct shash_desc *desc, void *out)
 {
 	memcpy(out, shash_desc_ctx(desc), crypto_shash_descsize(desc->tfm));
diff --git a/include/crypto/hash.h b/include/crypto/hash.h
index cee446c59497c6..4829d2367eda87 100644
--- a/include/crypto/hash.h
+++ b/include/crypto/hash.h
@@ -855,6 +855,25 @@ int crypto_shash_setkey(struct crypto_shash *tfm, const u8 *key,
 int crypto_shash_digest(struct shash_desc *desc, const u8 *data,
 			unsigned int len, u8 *out);
 
+/**
+ * crypto_shash_tfm_digest() - calculate message digest for buffer
+ * @tfm: hash transformation object
+ * @data: see crypto_shash_update()
+ * @len: see crypto_shash_update()
+ * @out: see crypto_shash_final()
+ *
+ * This is a simplified version of crypto_shash_digest() for users who don't
+ * want to allocate their own hash descriptor (shash_desc).  Instead,
+ * crypto_shash_tfm_digest() takes a hash transformation object (crypto_shash)
+ * directly, and it allocates a hash descriptor on the stack internally.
+ * Note that this stack allocation may be fairly large.
+ *
+ * Context: Any context.
+ * Return: 0 on success; < 0 if an error occurred.
+ */
+int crypto_shash_tfm_digest(struct crypto_shash *tfm, const u8 *data,
+			    unsigned int len, u8 *out);
+
 /**
  * crypto_shash_export() - extract operational state for message digest
  * @desc: reference to the operational state handle whose state is exported
-- 
2.26.2


WARNING: multiple messages have this Message-ID (diff)
From: Eric Biggers <ebiggers@kernel.org>
To: linux-crypto@vger.kernel.org
Cc: Cheng-Yi Chiang <cychiang@chromium.org>,
	ecryptfs@vger.kernel.org,
	Enric Balletbo i Serra <enric.balletbo@collabora.com>,
	Gilad Ben-Yossef <gilad@benyossef.com>,
	Guenter Roeck <groeck@chromium.org>,
	Jesper Nilsson <jesper.nilsson@axis.com>,
	Kamil Konieczny <k.konieczny@samsung.com>,
	keyrings@vger.kernel.org, Krzysztof Kozlowski <krzk@kernel.org>,
	Krzysztof Opasiak <k.opasiak@samsung.com>,
	Lars Persson <lars.persson@axis.com>,
	linux-bluetooth@vger.kernel.org, linux-mtd@lists.infradead.org,
	linux-nfs@vger.kernel.org, linux-sctp@vger.kernel.org,
	Robert Baldyga <r.baldyga@samsung.com>,
	Tom Lendacky <thomas.lendacky@amd.com>,
	Vladimir Zapolskiy <vz@mleia.com>, Zaibo Xu <xuzaibo@huawei.com>
Subject: [PATCH 01/20] crypto: hash - introduce crypto_shash_tfm_digest()
Date: Sat, 02 May 2020 05:31:03 +0000	[thread overview]
Message-ID: <20200502053122.995648-2-ebiggers@kernel.org> (raw)
In-Reply-To: <20200502053122.995648-1-ebiggers@kernel.org>

From: Eric Biggers <ebiggers@google.com>

Currently the simplest use of the shash API is to use
crypto_shash_digest() to digest a whole buffer.  However, this still
requires allocating a hash descriptor (struct shash_desc).  Many users
don't really want to preallocate one and instead just use a one-off
descriptor on the stack like the following:

	{
		SHASH_DESC_ON_STACK(desc, tfm);
		int err;

		desc->tfm = tfm;

		err = crypto_shash_digest(desc, data, len, out);

		shash_desc_zero(desc);
	}

Wrap this in a new helper function crypto_shash_tfm_digest() that can be
used instead of the above.

Signed-off-by: Eric Biggers <ebiggers@google.com>
---
 crypto/shash.c        | 16 ++++++++++++++++
 include/crypto/hash.h | 19 +++++++++++++++++++
 2 files changed, 35 insertions(+)

diff --git a/crypto/shash.c b/crypto/shash.c
index c075b26c2a1d9f..e6a4b5f39b8c64 100644
--- a/crypto/shash.c
+++ b/crypto/shash.c
@@ -206,6 +206,22 @@ int crypto_shash_digest(struct shash_desc *desc, const u8 *data,
 }
 EXPORT_SYMBOL_GPL(crypto_shash_digest);
 
+int crypto_shash_tfm_digest(struct crypto_shash *tfm, const u8 *data,
+			    unsigned int len, u8 *out)
+{
+	SHASH_DESC_ON_STACK(desc, tfm);
+	int err;
+
+	desc->tfm = tfm;
+
+	err = crypto_shash_digest(desc, data, len, out);
+
+	shash_desc_zero(desc);
+
+	return err;
+}
+EXPORT_SYMBOL_GPL(crypto_shash_tfm_digest);
+
 static int shash_default_export(struct shash_desc *desc, void *out)
 {
 	memcpy(out, shash_desc_ctx(desc), crypto_shash_descsize(desc->tfm));
diff --git a/include/crypto/hash.h b/include/crypto/hash.h
index cee446c59497c6..4829d2367eda87 100644
--- a/include/crypto/hash.h
+++ b/include/crypto/hash.h
@@ -855,6 +855,25 @@ int crypto_shash_setkey(struct crypto_shash *tfm, const u8 *key,
 int crypto_shash_digest(struct shash_desc *desc, const u8 *data,
 			unsigned int len, u8 *out);
 
+/**
+ * crypto_shash_tfm_digest() - calculate message digest for buffer
+ * @tfm: hash transformation object
+ * @data: see crypto_shash_update()
+ * @len: see crypto_shash_update()
+ * @out: see crypto_shash_final()
+ *
+ * This is a simplified version of crypto_shash_digest() for users who don't
+ * want to allocate their own hash descriptor (shash_desc).  Instead,
+ * crypto_shash_tfm_digest() takes a hash transformation object (crypto_shash)
+ * directly, and it allocates a hash descriptor on the stack internally.
+ * Note that this stack allocation may be fairly large.
+ *
+ * Context: Any context.
+ * Return: 0 on success; < 0 if an error occurred.
+ */
+int crypto_shash_tfm_digest(struct crypto_shash *tfm, const u8 *data,
+			    unsigned int len, u8 *out);
+
 /**
  * crypto_shash_export() - extract operational state for message digest
  * @desc: reference to the operational state handle whose state is exported
-- 
2.26.2

WARNING: multiple messages have this Message-ID (diff)
From: Eric Biggers <ebiggers@kernel.org>
To: linux-crypto@vger.kernel.org
Cc: Tom Lendacky <thomas.lendacky@amd.com>,
	Jesper Nilsson <jesper.nilsson@axis.com>,
	linux-bluetooth@vger.kernel.org,
	Kamil Konieczny <k.konieczny@samsung.com>,
	Robert Baldyga <r.baldyga@samsung.com>,
	ecryptfs@vger.kernel.org,
	Krzysztof Opasiak <k.opasiak@samsung.com>,
	linux-nfs@vger.kernel.org, Krzysztof Kozlowski <krzk@kernel.org>,
	Vladimir Zapolskiy <vz@mleia.com>,
	Gilad Ben-Yossef <gilad@benyossef.com>,
	linux-sctp@vger.kernel.org, keyrings@vger.kernel.org,
	linux-mtd@lists.infradead.org,
	Lars Persson <lars.persson@axis.com>,
	Enric Balletbo i Serra <enric.balletbo@collabora.com>,
	Guenter Roeck <groeck@chromium.org>,
	Zaibo Xu <xuzaibo@huawei.com>,
	Cheng-Yi Chiang <cychiang@chromium.org>
Subject: [PATCH 01/20] crypto: hash - introduce crypto_shash_tfm_digest()
Date: Fri,  1 May 2020 22:31:03 -0700	[thread overview]
Message-ID: <20200502053122.995648-2-ebiggers@kernel.org> (raw)
In-Reply-To: <20200502053122.995648-1-ebiggers@kernel.org>

From: Eric Biggers <ebiggers@google.com>

Currently the simplest use of the shash API is to use
crypto_shash_digest() to digest a whole buffer.  However, this still
requires allocating a hash descriptor (struct shash_desc).  Many users
don't really want to preallocate one and instead just use a one-off
descriptor on the stack like the following:

	{
		SHASH_DESC_ON_STACK(desc, tfm);
		int err;

		desc->tfm = tfm;

		err = crypto_shash_digest(desc, data, len, out);

		shash_desc_zero(desc);
	}

Wrap this in a new helper function crypto_shash_tfm_digest() that can be
used instead of the above.

Signed-off-by: Eric Biggers <ebiggers@google.com>
---
 crypto/shash.c        | 16 ++++++++++++++++
 include/crypto/hash.h | 19 +++++++++++++++++++
 2 files changed, 35 insertions(+)

diff --git a/crypto/shash.c b/crypto/shash.c
index c075b26c2a1d9f..e6a4b5f39b8c64 100644
--- a/crypto/shash.c
+++ b/crypto/shash.c
@@ -206,6 +206,22 @@ int crypto_shash_digest(struct shash_desc *desc, const u8 *data,
 }
 EXPORT_SYMBOL_GPL(crypto_shash_digest);
 
+int crypto_shash_tfm_digest(struct crypto_shash *tfm, const u8 *data,
+			    unsigned int len, u8 *out)
+{
+	SHASH_DESC_ON_STACK(desc, tfm);
+	int err;
+
+	desc->tfm = tfm;
+
+	err = crypto_shash_digest(desc, data, len, out);
+
+	shash_desc_zero(desc);
+
+	return err;
+}
+EXPORT_SYMBOL_GPL(crypto_shash_tfm_digest);
+
 static int shash_default_export(struct shash_desc *desc, void *out)
 {
 	memcpy(out, shash_desc_ctx(desc), crypto_shash_descsize(desc->tfm));
diff --git a/include/crypto/hash.h b/include/crypto/hash.h
index cee446c59497c6..4829d2367eda87 100644
--- a/include/crypto/hash.h
+++ b/include/crypto/hash.h
@@ -855,6 +855,25 @@ int crypto_shash_setkey(struct crypto_shash *tfm, const u8 *key,
 int crypto_shash_digest(struct shash_desc *desc, const u8 *data,
 			unsigned int len, u8 *out);
 
+/**
+ * crypto_shash_tfm_digest() - calculate message digest for buffer
+ * @tfm: hash transformation object
+ * @data: see crypto_shash_update()
+ * @len: see crypto_shash_update()
+ * @out: see crypto_shash_final()
+ *
+ * This is a simplified version of crypto_shash_digest() for users who don't
+ * want to allocate their own hash descriptor (shash_desc).  Instead,
+ * crypto_shash_tfm_digest() takes a hash transformation object (crypto_shash)
+ * directly, and it allocates a hash descriptor on the stack internally.
+ * Note that this stack allocation may be fairly large.
+ *
+ * Context: Any context.
+ * Return: 0 on success; < 0 if an error occurred.
+ */
+int crypto_shash_tfm_digest(struct crypto_shash *tfm, const u8 *data,
+			    unsigned int len, u8 *out);
+
 /**
  * crypto_shash_export() - extract operational state for message digest
  * @desc: reference to the operational state handle whose state is exported
-- 
2.26.2


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

  reply	other threads:[~2020-05-02  5:33 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-02  5:31 [PATCH 00/20] crypto: introduce crypto_shash_tfm_digest() Eric Biggers
2020-05-02  5:31 ` Eric Biggers
2020-05-02  5:31 ` Eric Biggers
2020-05-02  5:31 ` Eric Biggers [this message]
2020-05-02  5:31   ` [PATCH 01/20] crypto: hash - " Eric Biggers
2020-05-02  5:31   ` Eric Biggers
2020-05-02  5:31 ` [PATCH 02/20] crypto: arm64/aes-glue - use crypto_shash_tfm_digest() Eric Biggers
2020-05-02  5:31 ` [PATCH 03/20] crypto: essiv " Eric Biggers
2020-05-02  5:31 ` [PATCH 04/20] crypto: artpec6 " Eric Biggers
2020-05-02  5:31 ` [PATCH 05/20] crypto: ccp " Eric Biggers
2020-05-07 21:23   ` Tom Lendacky
2020-05-02  5:31 ` [PATCH 06/20] crypto: ccree " Eric Biggers
2020-05-03 14:01   ` Gilad Ben-Yossef
2020-05-02  5:31 ` [PATCH 07/20] crypto: hisilicon/sec2 " Eric Biggers
2020-05-02  5:31 ` [PATCH 08/20] crypto: mediatek " Eric Biggers
2020-05-02  5:31 ` [PATCH 09/20] crypto: n2 " Eric Biggers
2020-05-02  5:31 ` [PATCH 10/20] crypto: omap-sham " Eric Biggers
2020-05-02  5:31 ` [PATCH 11/20] crypto: s5p-sss " Eric Biggers
2020-05-05 14:19   ` Krzysztof Kozlowski
2020-05-02  5:31 ` [PATCH 12/20] nfc: s3fwrn5: " Eric Biggers
2020-05-02  5:31 ` [PATCH 13/20] fscrypt: " Eric Biggers
2020-05-02  5:31 ` [PATCH 14/20] ecryptfs: " Eric Biggers
2020-05-02  5:31 ` [PATCH 15/20] nfsd: " Eric Biggers
2020-05-04 19:09   ` J. Bruce Fields
2020-05-02  5:31 ` [PATCH 16/20] ubifs: " Eric Biggers
2020-05-02  5:31   ` Eric Biggers
2020-05-02  5:31 ` [PATCH 17/20] Bluetooth: " Eric Biggers
2020-05-02  5:31 ` [PATCH 18/20] sctp: " Eric Biggers
2020-05-02  5:31   ` Eric Biggers
2020-05-02  5:31 ` [PATCH 19/20] KEYS: encrypted: " Eric Biggers
2020-05-02  5:31   ` Eric Biggers
2020-05-02  5:31 ` [PATCH 20/20] ASoC: cros_ec_codec: " Eric Biggers
2020-05-02  6:44 ` [PATCH 00/20] crypto: introduce crypto_shash_tfm_digest() Marcel Holtmann
2020-05-02  6:44   ` Marcel Holtmann
2020-05-02  6:44   ` Marcel Holtmann
2020-05-03 16:13 ` Ard Biesheuvel
2020-05-03 16:13   ` Ard Biesheuvel
2020-05-03 16:13   ` Ard Biesheuvel
2020-05-08  6:07 ` Herbert Xu
2020-05-08  6:07   ` Herbert Xu
2020-05-08  6:07   ` Herbert Xu

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=20200502053122.995648-2-ebiggers@kernel.org \
    --to=ebiggers@kernel.org \
    --cc=cychiang@chromium.org \
    --cc=ecryptfs@vger.kernel.org \
    --cc=enric.balletbo@collabora.com \
    --cc=gilad@benyossef.com \
    --cc=groeck@chromium.org \
    --cc=jesper.nilsson@axis.com \
    --cc=k.konieczny@samsung.com \
    --cc=k.opasiak@samsung.com \
    --cc=keyrings@vger.kernel.org \
    --cc=krzk@kernel.org \
    --cc=lars.persson@axis.com \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=linux-sctp@vger.kernel.org \
    --cc=r.baldyga@samsung.com \
    --cc=thomas.lendacky@amd.com \
    --cc=vz@mleia.com \
    --cc=xuzaibo@huawei.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.