linux-crypto.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: Mikulas Patocka <mpatocka@redhat.com>, linux-crypto@vger.kernel.org
Cc: dm-devel@redhat.com
Subject: [PATCH v2 5/7] crypto: algapi - introduce the flag CRYPTO_ALG_ALLOCATES_MEMORY
Date: Thu,  9 Jul 2020 23:20:40 -0700	[thread overview]
Message-ID: <20200710062042.113842-6-ebiggers@kernel.org> (raw)
In-Reply-To: <20200710062042.113842-1-ebiggers@kernel.org>

From: Eric Biggers <ebiggers@google.com>

Introduce a new algorithm flag CRYPTO_ALG_ALLOCATES_MEMORY.  If this
flag is set, then the driver allocates memory in its request routine.
Such drivers are not suitable for disk encryption because GFP_ATOMIC
allocation can fail anytime (causing random I/O errors) and GFP_KERNEL
allocation can recurse into the block layer, causing a deadlock.

For now, this flag is only implemented for some algorithm types.  We
also assume some usage constraints for it to be meaningful, since there
are lots of edge cases the crypto API allows (e.g., misaligned or
fragmented scatterlists) that mean that nearly any crypto algorithm can
allocate memory in some case.  See the comment for details.

Also add this flag to CRYPTO_ALG_INHERITED_FLAGS so that when a template
is instantiated, this flag is set on the template instance if it is set
on any algorithm the instance uses.

Based on a patch by Mikulas Patocka <mpatocka@redhat.com>
(https://lore.kernel.org/r/alpine.LRH.2.02.2006301414580.30526@file01.intranet.prod.int.rdu2.redhat.com).

Signed-off-by: Eric Biggers <ebiggers@google.com>
---
 include/crypto/algapi.h |  3 ++-
 include/linux/crypto.h  | 32 ++++++++++++++++++++++++++++++++
 2 files changed, 34 insertions(+), 1 deletion(-)

diff --git a/include/crypto/algapi.h b/include/crypto/algapi.h
index 22cf4d80959f..143d884d65c7 100644
--- a/include/crypto/algapi.h
+++ b/include/crypto/algapi.h
@@ -246,7 +246,8 @@ static inline u32 crypto_requires_off(struct crypto_attr_type *algt, u32 off)
  * algorithm if any "inner" algorithm has them set.
  */
 #define CRYPTO_ALG_INHERITED_FLAGS	\
-	(CRYPTO_ALG_ASYNC | CRYPTO_ALG_NEED_FALLBACK)
+	(CRYPTO_ALG_ASYNC | CRYPTO_ALG_NEED_FALLBACK |	\
+	 CRYPTO_ALG_ALLOCATES_MEMORY)
 
 /*
  * Given the type and mask that specify the flags restrictions on a template
diff --git a/include/linux/crypto.h b/include/linux/crypto.h
index f73f0b51e1cd..ef90e07c9635 100644
--- a/include/linux/crypto.h
+++ b/include/linux/crypto.h
@@ -100,6 +100,38 @@
  */
 #define CRYPTO_NOLOAD			0x00008000
 
+/*
+ * The algorithm may allocate memory during request processing, i.e. during
+ * encryption, decryption, or hashing.  Users can request an algorithm with this
+ * flag unset if they can't handle memory allocation failures.
+ *
+ * This flag is currently only implemented for algorithms of type "skcipher",
+ * "aead", "ahash", "shash", and "cipher".  Algorithms of other types might not
+ * have this flag set even if they allocate memory.
+ *
+ * In some edge cases, algorithms can allocate memory regardless of this flag.
+ * To avoid these cases, users must obey the following usage constraints:
+ *    skcipher:
+ *	- The IV buffer and all scatterlist elements must be aligned to the
+ *	  algorithm's alignmask.
+ *	- If the data were to be divided into chunks of size
+ *	  crypto_skcipher_walksize() (with any remainder going at the end), no
+ *	  chunk can cross a page boundary or a scatterlist element boundary.
+ *    aead:
+ *	- The IV buffer and all scatterlist elements must be aligned to the
+ *	  algorithm's alignmask.
+ *	- The first scatterlist element must contain all the associated data,
+ *	  and its pages must be !PageHighMem.
+ *	- If the plaintext/ciphertext were to be divided into chunks of size
+ *	  crypto_aead_walksize() (with the remainder going at the end), no chunk
+ *	  can cross a page boundary or a scatterlist element boundary.
+ *    ahash:
+ *	- The result buffer must be aligned to the algorithm's alignmask.
+ *	- crypto_ahash_finup() must not be used unless the algorithm implements
+ *	  ->finup() natively.
+ */
+#define CRYPTO_ALG_ALLOCATES_MEMORY	0x00010000
+
 /*
  * Transform masks and values (for crt_flags).
  */
-- 
2.27.0


  parent reply	other threads:[~2020-07-10  6:21 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-10  6:20 [PATCH v2 0/7] crypto: add CRYPTO_ALG_ALLOCATES_MEMORY Eric Biggers
2020-07-10  6:20 ` [PATCH v2 1/7] crypto: geniv - remove unneeded arguments from aead_geniv_alloc() Eric Biggers
2020-07-10  6:20 ` [PATCH v2 2/7] crypto: seqiv - remove seqiv_create() Eric Biggers
2020-07-10  6:20 ` [PATCH v2 3/7] crypto: algapi - use common mechanism for inheriting flags Eric Biggers
2020-07-10  6:20 ` [PATCH v2 4/7] crypto: algapi - add NEED_FALLBACK to INHERITED_FLAGS Eric Biggers
2020-07-10  6:20 ` Eric Biggers [this message]
2020-07-10  6:20 ` [PATCH v2 6/7] crypto: drivers - set the flag CRYPTO_ALG_ALLOCATES_MEMORY Eric Biggers
2020-07-10  6:20 ` [PATCH v2 7/7] dm-crypt: don't use drivers that have CRYPTO_ALG_ALLOCATES_MEMORY Eric Biggers
2020-07-16 11:55 ` [PATCH v2 0/7] crypto: add CRYPTO_ALG_ALLOCATES_MEMORY Herbert Xu
2020-07-17 14:42   ` Horia Geantă
2020-07-22  7:29     ` Herbert Xu
2020-11-19 18:29       ` Iuliana Prodan

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=20200710062042.113842-6-ebiggers@kernel.org \
    --to=ebiggers@kernel.org \
    --cc=dm-devel@redhat.com \
    --cc=linux-crypto@vger.kernel.org \
    --cc=mpatocka@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).