16 Jul, 2020
2 commits
-
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
(https://lore.kernel.org/r/alpine.LRH.2.02.2006301414580.30526@file01.intranet.prod.int.rdu2.redhat.com).Signed-off-by: Eric Biggers
Signed-off-by: Herbert Xu -
CRYPTO_ALG_NEED_FALLBACK is handled inconsistently. When it's requested
to be clear, some templates propagate that request to child algorithms,
while others don't.It's apparently desired for NEED_FALLBACK to be propagated, to avoid
deadlocks where a module tries to load itself while it's being
initialized, and to avoid unnecessarily complex fallback chains where we
have e.g. cbc-aes-$driver falling back to cbc(aes-$driver) where
aes-$driver itself falls back to aes-generic, instead of cbc-aes-$driver
simply falling back to cbc(aes-generic). There have been a number of
fixes to this effect:commit 89027579bc6c ("crypto: xts - Propagate NEED_FALLBACK bit")
commit d2c2a85cfe82 ("crypto: ctr - Propagate NEED_FALLBACK bit")
commit e6c2e65c70a6 ("crypto: cbc - Propagate NEED_FALLBACK bit")But it seems that other templates can have the same problems too.
To avoid this whack-a-mole, just add NEED_FALLBACK to INHERITED_FLAGS so
that it's always inherited.Signed-off-by: Eric Biggers
Signed-off-by: Herbert Xu
09 Jul, 2020
1 commit
-
For a Linux server with NUMA, there are possibly multiple (de)compressors
which are either local or remote to some NUMA node. Some drivers will
automatically use the (de)compressor near the CPU calling acomp_alloc().
However, it is not necessarily correct because users who send acomp_req
could be from different NUMA node with the CPU which allocates acomp.Just like kernel has kmalloc() and kmalloc_node(), here crypto can have
same support.Cc: Seth Jennings
Cc: Dan Streetman
Cc: Vitaly Wool
Cc: Andrew Morton
Cc: Jonathan Cameron
Signed-off-by: Barry Song
Signed-off-by: Herbert Xu
26 Jun, 2020
1 commit
-
We haven't used string.h since the memcpy calls were removed so
this patch removes its inclusion. The file uaccess.h isn't needed
at all. However, removing it reveals that we do need to add an
inclusion for refcount.h.Signed-off-by: Herbert Xu
09 Jan, 2020
5 commits
-
The CRYPTO_TFM_RES_* flags were apparently meant as a way to make the
->setkey() functions provide more information about errors. But these
flags weren't actually being used or tested, and in many cases they
weren't being set correctly anyway. So they've now been removed.Also, if someone ever actually needs to start better distinguishing
->setkey() errors (which is somewhat unlikely, as this has been unneeded
for a long time), we'd be much better off just defining different return
values, like -EINVAL if the key is invalid for the algorithm vs.
-EKEYREJECTED if the key was rejected by a policy like "no weak keys".
That would be much simpler, less error-prone, and easier to test.So just remove CRYPTO_TFM_RES_MASK and all the unneeded logic that
propagates these flags around.Signed-off-by: Eric Biggers
Signed-off-by: Herbert Xu -
The CRYPTO_TFM_RES_WEAK_KEY flag was apparently meant as a way to make
the ->setkey() functions provide more information about errors.However, no one actually checks for this flag, which makes it pointless.
There are also no tests that verify that all algorithms actually set (or
don't set) it correctly.This is also the last remaining CRYPTO_TFM_RES_* flag, which means that
it's the only thing still needing all the boilerplate code which
propagates these flags around from child => parent tfms.And if someone ever needs to distinguish this error in the future (which
is somewhat unlikely, as it's been unneeded for a long time), it would
be much better to just define a new return value like -EKEYREJECTED.
That would be much simpler, less error-prone, and easier to test.So just remove this flag.
Signed-off-by: Eric Biggers
Signed-off-by: Herbert Xu -
The CRYPTO_TFM_RES_BAD_KEY_LEN flag was apparently meant as a way to
make the ->setkey() functions provide more information about errors.However, no one actually checks for this flag, which makes it pointless.
Also, many algorithms fail to set this flag when given a bad length key.
Reviewing just the generic implementations, this is the case for
aes-fixed-time, cbcmac, echainiv, nhpoly1305, pcrypt, rfc3686, rfc4309,
rfc7539, rfc7539esp, salsa20, seqiv, and xcbc. But there are probably
many more in arch/*/crypto/ and drivers/crypto/.Some algorithms can even set this flag when the key is the correct
length. For example, authenc and authencesn set it when the key payload
is malformed in any way (not just a bad length), the atmel-sha and ccree
drivers can set it if a memory allocation fails, and the chelsio driver
sets it for bad auth tag lengths, not just bad key lengths.So even if someone actually wanted to start checking this flag (which
seems unlikely, since it's been unused for a long time), there would be
a lot of work needed to get it working correctly. But it would probably
be much better to go back to the drawing board and just define different
return values, like -EINVAL if the key is invalid for the algorithm vs.
-EKEYREJECTED if the key was rejected by a policy like "no weak keys".
That would be much simpler, less error-prone, and easier to test.So just remove this flag.
Signed-off-by: Eric Biggers
Reviewed-by: Horia Geantă
Signed-off-by: Herbert Xu -
The flag CRYPTO_TFM_RES_BAD_BLOCK_LEN is never checked for, and it's
only set by one driver. And even that single driver's use is wrong
because the driver is setting the flag from ->encrypt() and ->decrypt()
with no locking, which is unsafe because ->encrypt() and ->decrypt() can
be executed by many threads in parallel on the same tfm.Just remove this flag.
Signed-off-by: Eric Biggers
Signed-off-by: Herbert Xu -
The tfm result flags CRYPTO_TFM_RES_BAD_KEY_SCHED and
CRYPTO_TFM_RES_BAD_FLAGS are never used, so remove them.Signed-off-by: Eric Biggers
Signed-off-by: Herbert Xu
27 Dec, 2019
1 commit
-
Fixes coccicheck warning:
./include/linux/crypto.h:573:2-3: Unneeded semicolon
Signed-off-by: Chen Zhou
Signed-off-by: Herbert Xu
20 Dec, 2019
1 commit
-
Some of the algorithm unregistration functions return -ENOENT when asked
to unregister a non-registered algorithm, while others always return 0
or always return void. But no users check the return value, except for
two of the bulk unregistration functions which print a message on error
but still always return 0 to their caller, and crypto_del_alg() which
calls crypto_unregister_instance() which always returns 0.Since unregistering a non-registered algorithm is always a kernel bug
but there isn't anything callers should do to handle this situation at
runtime, let's simplify things by making all the unregistration
functions return void, and moving the error message into
crypto_unregister_alg() and upgrading it to a WARN().Signed-off-by: Eric Biggers
Signed-off-by: Herbert Xu
11 Dec, 2019
2 commits
-
Of the three fields in crt_u.cipher (struct cipher_tfm), ->cit_setkey()
is pointless because it always points to setkey() in crypto/cipher.c.->cit_decrypt_one() and ->cit_encrypt_one() are slightly less pointless,
since if the algorithm doesn't have an alignmask, they are set directly
to ->cia_encrypt() and ->cia_decrypt(). However, this "optimization"
isn't worthwhile because:- The "cipher" algorithm type is the only algorithm still using crt_u,
so it's bloating every struct crypto_tfm for every algorithm type.- If the algorithm has an alignmask, this "optimization" actually makes
things slower, as it causes 2 indirect calls per block rather than 1.- It adds extra code complexity.
- Some templates already call ->cia_encrypt()/->cia_decrypt() directly
instead of going through ->cit_encrypt_one()/->cit_decrypt_one().- The "cipher" algorithm type never gives optimal performance anyway.
For that, a higher-level type such as skcipher needs to be used.Therefore, just remove the extra indirection, and make
crypto_cipher_setkey(), crypto_cipher_encrypt_one(), and
crypto_cipher_decrypt_one() be direct calls into crypto/cipher.c.Also remove the unused function crypto_cipher_cast().
Signed-off-by: Eric Biggers
Signed-off-by: Herbert Xu -
crt_u.compress (struct compress_tfm) is pointless because its two
fields, ->cot_compress() and ->cot_decompress(), always point to
crypto_compress() and crypto_decompress().Remove this pointless indirection, and just make crypto_comp_compress()
and crypto_comp_decompress() be direct calls to what used to be
crypto_compress() and crypto_decompress().Also remove the unused function crypto_comp_cast().
Signed-off-by: Eric Biggers
Signed-off-by: Herbert Xu
17 Nov, 2019
1 commit
-
Now that all users of the deprecated ablkcipher interface have been
moved to the skcipher interface, ablkcipher is no longer used and
can be removed.Reviewed-by: Eric Biggers
Signed-off-by: Ard Biesheuvel
Signed-off-by: Herbert Xu
01 Nov, 2019
2 commits
-
Now that all "blkcipher" algorithms have been converted to "skcipher",
remove the blkcipher algorithm type.The skcipher (symmetric key cipher) algorithm type was introduced a few
years ago to replace both blkcipher and ablkcipher (synchronous and
asynchronous block cipher). The advantages of skcipher include:- A much less confusing name, since none of these algorithm types have
ever actually been for raw block ciphers, but rather for all
length-preserving encryption modes including block cipher modes of
operation, stream ciphers, and other length-preserving modes.- It unified blkcipher and ablkcipher into a single algorithm type
which supports both synchronous and asynchronous implementations.
Note, blkcipher already operated only on scatterlists, so the fact
that skcipher does too isn't a regression in functionality.- Better type safety by using struct skcipher_alg, struct
crypto_skcipher, etc. instead of crypto_alg, crypto_tfm, etc.- It sometimes simplifies the implementations of algorithms.
Also, the blkcipher API was no longer being tested.
Signed-off-by: Eric Biggers
Signed-off-by: Herbert Xu -
crypto_has_ablkcipher() has no users, and it does the same thing as
crypto_has_skcipher() anyway. So remove it. This also removes the last
user of crypto_skcipher_type() and crypto_skcipher_mask(), so remove
those too.Signed-off-by: Eric Biggers
Signed-off-by: Herbert Xu
09 Jul, 2019
1 commit
-
Pull crypto updates from Herbert Xu:
"Here is the crypto update for 5.3:API:
- Test shash interface directly in testmgr
- cra_driver_name is now mandatoryAlgorithms:
- Replace arc4 crypto_cipher with library helper
- Implement 5 way interleave for ECB, CBC and CTR on arm64
- Add xxhash
- Add continuous self-test on noise source to drbg
- Update jitter RNGDrivers:
- Add support for SHA204A random number generator
- Add support for 7211 in iproc-rng200
- Fix fuzz test failures in inside-secure
- Fix fuzz test failures in talitos
- Fix fuzz test failures in qat"* 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: (143 commits)
crypto: stm32/hash - remove interruptible condition for dma
crypto: stm32/hash - Fix hmac issue more than 256 bytes
crypto: stm32/crc32 - rename driver file
crypto: amcc - remove memset after dma_alloc_coherent
crypto: ccp - Switch to SPDX license identifiers
crypto: ccp - Validate the the error value used to index error messages
crypto: doc - Fix formatting of new crypto engine content
crypto: doc - Add parameter documentation
crypto: arm64/aes-ce - implement 5 way interleave for ECB, CBC and CTR
crypto: arm64/aes-ce - add 5 way interleave routines
crypto: talitos - drop icv_ool
crypto: talitos - fix hash on SEC1.
crypto: talitos - move struct talitos_edesc into talitos.h
lib/scatterlist: Fix mapping iterator when sg->offset is greater than PAGE_SIZE
crypto/NX: Set receive window credits to max number of CRBs in RxFIFO
crypto: asymmetric_keys - select CRYPTO_HASH where needed
crypto: serpent - mark __serpent_setkey_sbox noinline
crypto: testmgr - dynamically allocate crypto_shash
crypto: testmgr - dynamically allocate testvec_config
crypto: talitos - eliminate unneeded 'done' functions at build time
...
03 Jul, 2019
1 commit
-
Fill in missing parameter descriptions for the compression algorithm,
then pick them up to document for the compression_alg structure.Signed-off-by: Gary R Hook
Signed-off-by: Herbert Xu
31 May, 2019
1 commit
-
Based on 1 normalized pattern(s):
this program is free software you can redistribute it and or modify
it under the terms of the gnu general public license as published by
the free software foundation either version 2 of the license or at
your option any later versionextracted by the scancode license scanner the SPDX license identifier
GPL-2.0-or-later
has been chosen to replace the boilerplate/reference in 3029 file(s).
Signed-off-by: Thomas Gleixner
Reviewed-by: Allison Randal
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190527070032.746973796@linutronix.de
Signed-off-by: Greg Kroah-Hartman
30 May, 2019
1 commit
-
Remove the unnecessary constant CRYPTO_ALG_TYPE_DIGEST, which has the
same value as CRYPTO_ALG_TYPE_HASH.Signed-off-by: Eric Biggers
Signed-off-by: Herbert Xu
25 Jan, 2019
1 commit
-
CRYPTO_TFM_REQ_WEAK_KEY confuses newcomers to the crypto API because it
sounds like it is requesting a weak key. Actually, it is requesting
that weak keys be forbidden (for algorithms that have the notion of
"weak keys"; currently only DES and XTS do).Also it is only one letter away from CRYPTO_TFM_RES_WEAK_KEY, with which
it can be easily confused. (This in fact happened in the UX500 driver,
though just in some debugging messages.)Therefore, make the intent clear by renaming it to
CRYPTO_TFM_REQ_FORBID_WEAK_KEYS.Signed-off-by: Eric Biggers
Signed-off-by: Herbert Xu
11 Jan, 2019
1 commit
-
'struct cipher_desc' is unused. Remove it.
Signed-off-by: Eric Biggers
Signed-off-by: Herbert Xu
23 Dec, 2018
2 commits
-
Remove dead code related to internal IV generators, which are no longer
used since they've been replaced with the "seqiv" and "echainiv"
templates. The removed code includes:- The "givcipher" (GIVCIPHER) algorithm type. No algorithms are
registered with this type anymore, so it's unneeded.- The "const char *geniv" member of aead_alg, ablkcipher_alg, and
blkcipher_alg. A few algorithms still set this, but it isn't used
anymore except to show via /proc/crypto and CRYPTO_MSG_GETALG.
Just hardcode "" or "" in those cases.- The 'skcipher_givcrypt_request' structure, which is never used.
Signed-off-by: Eric Biggers
Signed-off-by: Herbert Xu -
This patchs adds missing member of stats documentation.
Signed-off-by: Corentin Labbe
Signed-off-by: Herbert Xu
07 Dec, 2018
6 commits
-
This patch add the crypto_stats_init() function.
This will permit to remove some ifdef from __crypto_register_alg().Signed-off-by: Corentin Labbe
Signed-off-by: Herbert Xu -
Since now all crypto stats are on their own structures, it is now
useless to have the algorithm name in the err_cnt member.Signed-off-by: Corentin Labbe
Signed-off-by: Herbert Xu -
Like for userspace, this patch splits stats into multiple structures,
one for each algorithm class.
Signed-off-by: Corentin Labbe
Signed-off-by: Herbert Xu -
All crypto_stats functions use the struct xxx_request for feeding stats,
but in some case this structure could already be freed.For fixing this, the needed parameters (len and alg) will be stored
before the request being executed.
Fixes: cac5818c25d0 ("crypto: user - Implement a generic crypto statistics")
Reported-by: syzbotSigned-off-by: Corentin Labbe
Signed-off-by: Herbert Xu -
All the 32-bit fields need to be 64-bit. In some cases, UINT32_MAX crypto
operations can be done in seconds.Reported-by: Eric Biggers
Signed-off-by: Corentin Labbe
Signed-off-by: Herbert Xu -
Even if CRYPTO_STATS is set to n, some part of CRYPTO_STATS are
compiled.
This patch made all part of crypto_user_stat uncompiled in that case.Signed-off-by: Corentin Labbe
Signed-off-by: Herbert Xu
28 Sep, 2018
1 commit
-
This patch implement a generic way to get statistics about all crypto
usages.Signed-off-by: Corentin Labbe
Signed-off-by: Herbert Xu
18 Jul, 2018
1 commit
-
When EVM attempts to appraise a file signed with a crypto algorithm the
kernel doesn't have support for, it will cause the kernel to trigger a
module load. If the EVM policy includes appraisal of kernel modules this
will in turn call back into EVM - since EVM is holding a lock until the
crypto initialisation is complete, this triggers a deadlock. Add a
CRYPTO_NOLOAD flag and skip module loading if it's set, and add that flag
in the EVM case in order to fail gracefully with an error message
instead of deadlocking.Signed-off-by: Matthew Garrett
Acked-by: Herbert Xu
Signed-off-by: Mimi Zohar
23 Mar, 2018
1 commit
-
Add missing comments for union members ablkcipher, blkcipher,
cipher, and compress. This silences complaints when building
the htmldocs.Fixes: 0d7f488f0305a (crypto: doc - cipher data structures)
Signed-off-by: Gary R Hook
Signed-off-by: Herbert Xu
12 Jan, 2018
2 commits
-
Currently, almost none of the keyed hash algorithms check whether a key
has been set before proceeding. Some algorithms are okay with this and
will effectively just use a key of all 0's or some other bogus default.
However, others will severely break, as demonstrated using
"hmac(sha3-512-generic)", the unkeyed use of which causes a kernel crash
via a (potentially exploitable) stack buffer overflow.A while ago, this problem was solved for AF_ALG by pairing each hash
transform with a 'has_key' bool. However, there are still other places
in the kernel where userspace can specify an arbitrary hash algorithm by
name, and the kernel uses it as unkeyed hash without checking whether it
is really unkeyed. Examples of this include:- KEYCTL_DH_COMPUTE, via the KDF extension
- dm-verity
- dm-crypt, via the ESSIV support
- dm-integrity, via the "internal hash" mode with no key given
- drbd (Distributed Replicated Block Device)This bug is especially bad for KEYCTL_DH_COMPUTE as that requires no
privileges to call.Fix the bug for all users by adding a flag CRYPTO_TFM_NEED_KEY to the
->crt_flags of each hash transform that indicates whether the transform
still needs to be keyed or not. Then, make the hash init, import, and
digest functions return -ENOKEY if the key is still needed.The new flag also replaces the 'has_key' bool which algif_hash was
previously using, thereby simplifying the algif_hash implementation.Reported-by: syzbot
Cc: stable@vger.kernel.org
Signed-off-by: Eric Biggers
Signed-off-by: Herbert Xu -
We need to consistently enforce that keyed hashes cannot be used without
setting the key. To do this we need a reliable way to determine whether
a given hash algorithm is keyed or not. AF_ALG currently does this by
checking for the presence of a ->setkey() method. However, this is
actually slightly broken because the CRC-32 algorithms implement
->setkey() but can also be used without a key. (The CRC-32 "key" is not
actually a cryptographic key but rather represents the initial state.
If not overridden, then a default initial state is used.)Prepare to fix this by introducing a flag CRYPTO_ALG_OPTIONAL_KEY which
indicates that the algorithm has a ->setkey() method, but it is not
required to be called. Then set it on all the CRC-32 algorithms.The same also applies to the Adler-32 implementation in Lustre.
Also, the cryptd and mcryptd templates have to pass through the flag
from their underlying algorithm.Cc: stable@vger.kernel.org
Signed-off-by: Eric Biggers
Signed-off-by: Herbert Xu
05 Jan, 2018
1 commit
-
Reference counters should use refcount_t rather than atomic_t, since the
refcount_t implementation can prevent overflows, reducing the
exploitability of reference leak bugs. crypto_alg.cra_refcount is a
reference counter with the usual semantics, so switch it over to
refcount_t.Signed-off-by: Eric Biggers
Signed-off-by: Herbert Xu
03 Nov, 2017
1 commit
-
Invoking a possibly async. crypto op and waiting for completion
while correctly handling backlog processing is a common task
in the crypto API implementation and outside users of it.This patch adds a generic implementation for doing so in
preparation for using it across the board instead of hand
rolled versions.Signed-off-by: Gilad Ben-Yossef
CC: Eric Biggers
CC: Jonathan Cameron
Signed-off-by: Herbert Xu
10 Apr, 2017
1 commit
-
With the new explicit IV generators, we may now exceed the 64-byte
length limit on the algorithm name, e.g., withechainiv(authencesn(hmac(sha256-generic),cbc(des3_ede-generic)))
This patch extends the length limit to 128 bytes.
Reported-by: Alexander Sverdlin
Signed-off-by: Herbert Xu
Acked-by: Alexander Sverdlin
Tested-by: Alexander Sverdlin
18 Dec, 2016
1 commit
-
Pull more documentation updates from Jonathan Corbet:
"This converts the crypto DocBook to Sphinx"* tag 'docs-4.10-2' of git://git.lwn.net/linux:
crypto: doc - optimize compilation
crypto: doc - clarify AEAD memory structure
crypto: doc - remove crypto_alloc_ablkcipher
crypto: doc - add KPP documentation
crypto: doc - fix separation of cipher / req API
crypto: doc - fix source comments for Sphinx
crypto: doc - remove crypto API DocBook
crypto: doc - convert crypto API documentation to Sphinx
14 Dec, 2016
1 commit
-
Update comments to avoid any complaints from Sphinx during compilation.
Signed-off-by: Stephan Mueller
Signed-off-by: Jonathan Corbet
