08 Aug, 2020
1 commit
-
As said by Linus:
A symmetric naming is only helpful if it implies symmetries in use.
Otherwise it's actively misleading.In "kzalloc()", the z is meaningful and an important part of what the
caller wants.In "kzfree()", the z is actively detrimental, because maybe in the
future we really _might_ want to use that "memfill(0xdeadbeef)" or
something. The "zero" part of the interface isn't even _relevant_.The main reason that kzfree() exists is to clear sensitive information
that should not be leaked to other future users of the same memory
objects.Rename kzfree() to kfree_sensitive() to follow the example of the recently
added kvfree_sensitive() and make the intention of the API more explicit.
In addition, memzero_explicit() is used to clear the memory to make sure
that it won't get optimized away by the compiler.The renaming is done by using the command sequence:
git grep -w --name-only kzfree |\
xargs sed -i 's/kzfree/kfree_sensitive/'followed by some editing of the kfree_sensitive() kerneldoc and adding
a kzfree backward compatibility macro in slab.h.[akpm@linux-foundation.org: fs/crypto/inline_crypt.c needs linux/slab.h]
[akpm@linux-foundation.org: fix fs/crypto/inline_crypt.c some more]Suggested-by: Joe Perches
Signed-off-by: Waiman Long
Signed-off-by: Andrew Morton
Acked-by: David Howells
Acked-by: Michal Hocko
Acked-by: Johannes Weiner
Cc: Jarkko Sakkinen
Cc: James Morris
Cc: "Serge E. Hallyn"
Cc: Joe Perches
Cc: Matthew Wilcox
Cc: David Rientjes
Cc: Dan Carpenter
Cc: "Jason A . Donenfeld"
Link: http://lkml.kernel.org/r/20200616154311.12314-3-longman@redhat.com
Signed-off-by: Linus Torvalds
16 Jul, 2020
1 commit
-
The flag CRYPTO_ALG_ASYNC is "inherited" in the sense that when a
template is instantiated, the template will have CRYPTO_ALG_ASYNC set if
any of the algorithms it uses has CRYPTO_ALG_ASYNC set.We'd like to add a second flag (CRYPTO_ALG_ALLOCATES_MEMORY) that gets
"inherited" in the same way. This is difficult because the handling of
CRYPTO_ALG_ASYNC is hardcoded everywhere. Address this by:- Add CRYPTO_ALG_INHERITED_FLAGS, which contains the set of flags that
have these inheritance semantics.- Add crypto_algt_inherited_mask(), for use by template ->create()
methods. It returns any of these flags that the user asked to be
unset and thus must be passed in the 'mask' to crypto_grab_*().- Also modify crypto_check_attr_type() to handle computing the 'mask'
so that most templates can just use this.- Make crypto_grab_*() propagate these flags to the template instance
being created so that templates don't have to do this themselves.Make crypto/simd.c propagate these flags too, since it "wraps" another
algorithm, similar to a template.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
06 Mar, 2020
2 commits
-
Simplify the error handling in crypto_rfc4543_create() by taking
advantage of crypto_grab_aead() now handling an ERR_PTR() name and by
taking advantage of crypto_drop_aead() now accepting (as a no-op) a
spawn that hasn't been grabbed yet.Conveniently, this eliminates the 'ccm_name' variable which was
incorrectly named (it should have been 'gcm_name').Also fix a weird case where a line was terminated by a comma rather than
a semicolon, causing the statement to be continued on the next line.
Fortunately the code still behaved as intended, though.Signed-off-by: Eric Biggers
Signed-off-by: Herbert Xu -
Simplify the error handling in crypto_rfc4106_create() by taking
advantage of crypto_grab_aead() now handling an ERR_PTR() name and by
taking advantage of crypto_drop_aead() now accepting (as a no-op) a
spawn that hasn't been grabbed yet.Conveniently, this eliminates the 'ccm_name' variable which was
incorrectly named (it should have been 'gcm_name').Signed-off-by: Eric Biggers
Signed-off-by: Herbert Xu
09 Jan, 2020
4 commits
-
Make the gcm and gcm_base templates use the new function
crypto_grab_ahash() to initialize their ahash spawn.This is needed to make all spawns be initialized in a consistent way.
Also simplify the error handling by taking advantage of crypto_drop_*()
now accepting (as a no-op) spawns that haven't been initialized yet.Signed-off-by: Eric Biggers
Signed-off-by: Herbert Xu -
Initializing a crypto_aead_spawn currently requires:
1. Set spawn->base.inst to point to the instance.
2. Call crypto_grab_aead().But there's no reason for these steps to be separate, and in fact this
unneeded complication has caused at least one bug, the one fixed by
commit 6db43410179b ("crypto: adiantum - initialize crypto_spawn::inst")So just make crypto_grab_aead() take the instance as an argument.
To keep the function calls from getting too unwieldy due to this extra
argument, also introduce a 'mask' variable into the affected places
which weren't already using one.Signed-off-by: Eric Biggers
Signed-off-by: Herbert Xu -
Initializing a crypto_skcipher_spawn currently requires:
1. Set spawn->base.inst to point to the instance.
2. Call crypto_grab_skcipher().But there's no reason for these steps to be separate, and in fact this
unneeded complication has caused at least one bug, the one fixed by
commit 6db43410179b ("crypto: adiantum - initialize crypto_spawn::inst")So just make crypto_grab_skcipher() take the instance as an argument.
To keep the function calls from getting too unwieldy due to this extra
argument, also introduce a 'mask' variable into the affected places
which weren't already using one.Signed-off-by: Eric Biggers
Signed-off-by: Herbert Xu -
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
09 Aug, 2019
2 commits
-
Based on seqiv, IPsec ESP and rfc4543/rfc4106 the assoclen can be 16 or
20 bytes.From esp4/esp6, assoclen is sizeof IP Header. This includes spi, seq_no
and extended seq_no, that is 8 or 12 bytes.
In seqiv, to asscolen is added the IV size (8 bytes).
Therefore, the assoclen, for rfc4543, should be restricted to 16 or 20
bytes, as for rfc4106.Signed-off-by: Iuliana Prodan
Reviewed-by: Horia Geanta
Signed-off-by: Herbert Xu -
Added inline helper functions to check authsize and assoclen for
gcm, rfc4106 and rfc4543.
These are used in the generic implementation of gcm, rfc4106 and
rfc4543.Signed-off-by: Iuliana Prodan
Signed-off-by: Herbert Xu
19 Jun, 2019
1 commit
-
Based on 2 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 version 2 as
published by the free software foundationthis program is free software you can redistribute it and or modify
it under the terms of the gnu general public license version 2 as
published by the free software foundation #extracted by the scancode license scanner the SPDX license identifier
GPL-2.0-only
has been chosen to replace the boilerplate/reference in 4122 file(s).
Signed-off-by: Thomas Gleixner
Reviewed-by: Enrico Weigelt
Reviewed-by: Kate Stewart
Reviewed-by: Allison Randal
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190604081206.933168790@linutronix.de
Signed-off-by: Greg Kroah-Hartman
19 Apr, 2019
1 commit
-
GCM instances can be created by either the "gcm" template, which only
allows choosing the block cipher, e.g. "gcm(aes)"; or by "gcm_base",
which allows choosing the ctr and ghash implementations, e.g.
"gcm_base(ctr(aes-generic),ghash-generic)".However, a "gcm_base" instance prevents a "gcm" instance from being
registered using the same implementations. Nor will the instance be
found by lookups of "gcm". This can be used as a denial of service.
Moreover, "gcm_base" instances are never tested by the crypto
self-tests, even if there are compatible "gcm" tests.The root cause of these problems is that instances of the two templates
use different cra_names. Therefore, fix these problems by making
"gcm_base" instances set the same cra_name as "gcm" instances, e.g.
"gcm(aes)" instead of "gcm_base(ctr(aes-generic),ghash-generic)".This requires extracting the block cipher name from the name of the ctr
algorithm. It also requires starting to verify that the algorithms are
really ctr and ghash, not something else entirely. But it would be
bizarre if anyone were actually using non-gcm-compatible algorithms with
gcm_base, so this shouldn't break anyone in practice.Fixes: d00aa19b507b ("[CRYPTO] gcm: Allow block cipher parameter")
Cc: stable@vger.kernel.org
Signed-off-by: Eric Biggers
Signed-off-by: Herbert Xu
18 Apr, 2019
1 commit
-
Use subsys_initcall for registration of all templates and generic
algorithm implementations, rather than module_init. Then change
cryptomgr to use arch_initcall, to place it before the subsys_initcalls.This is needed so that when both a generic and optimized implementation
of an algorithm are built into the kernel (not loadable modules), the
generic implementation is registered before the optimized one.
Otherwise, the self-tests for the optimized implementation are unable to
allocate the generic implementation for the new comparison fuzz tests.Note that on arm, a side effect of this change is that self-tests for
generic implementations may run before the unaligned access handler has
been installed. So, unaligned accesses will crash the kernel. This is
arguably a good thing as it makes it easier to detect that type of bug.Signed-off-by: Eric Biggers
Signed-off-by: Herbert Xu
25 Jan, 2019
1 commit
-
Use crypto template array registering API to simplify the code.
Signed-off-by: Xiongfeng Wang
Reviewed-by: Eric Biggers
Signed-off-by: Herbert Xu
18 Jan, 2019
1 commit
-
In gcm_hash_len(), use be128 rather than u128. This fixes the following
sparse warnings:crypto/gcm.c:252:19: warning: incorrect type in assignment (different base types)
crypto/gcm.c:252:19: expected unsigned long long [usertype] a
crypto/gcm.c:252:19: got restricted __be64 [usertype]
crypto/gcm.c:253:19: warning: incorrect type in assignment (different base types)
crypto/gcm.c:253:19: expected unsigned long long [usertype] b
crypto/gcm.c:253:19: got restricted __be64 [usertype]No actual change in behavior.
Signed-off-by: Eric Biggers
Signed-off-by: Herbert Xu
28 Sep, 2018
1 commit
-
In the quest to remove all stack VLA usage from the kernel[1], this
replaces struct crypto_skcipher and SKCIPHER_REQUEST_ON_STACK() usage
with struct crypto_sync_skcipher and SYNC_SKCIPHER_REQUEST_ON_STACK(),
which uses a fixed stack size.[1] https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qPXydAacU1RqZWA@mail.gmail.com
Signed-off-by: Kees Cook
Signed-off-by: Herbert Xu
22 Dec, 2017
1 commit
-
Since commit 499a66e6b689 ("crypto: null - Remove default null
blkcipher"), crypto_get_default_null_skcipher2() and
crypto_put_default_null_skcipher2() are the same as their non-2
equivalents. So switch callers of the "2" versions over to the original
versions and remove the "2" versions.Signed-off-by: Eric Biggers
Signed-off-by: Herbert Xu
03 Nov, 2017
1 commit
-
gcm is starting an async. crypto op and waiting for it complete.
Move it over to generic code doing the same.Signed-off-by: Gilad Ben-Yossef
Signed-off-by: Herbert Xu
22 Sep, 2017
1 commit
-
This patch replace GCM IV size value by their constant name.
Signed-off-by: Corentin Labbe
Signed-off-by: Herbert Xu
23 May, 2017
1 commit
-
crypto_gcm_setkey() was using wait_for_completion_interruptible() to
wait for completion of async crypto op but if a signal occurs it
may return before DMA ops of HW crypto provider finish, thus
corrupting the data buffer that is kfree'ed in this case.Resolve this by using wait_for_completion() instead.
Reported-by: Eric Biggers
Signed-off-by: Gilad Ben-Yossef
CC: stable@vger.kernel.org
Signed-off-by: Herbert Xu
01 Nov, 2016
2 commits
-
Since commit 3a01d0ee2b99 ("crypto: skcipher - Remove top-level
givcipher interface"), crypto_spawn_skcipher2() and
crypto_spawn_skcipher() are equivalent. So switch callers of
crypto_spawn_skcipher2() to crypto_spawn_skcipher() and remove it.Signed-off-by: Eric Biggers
Signed-off-by: Herbert Xu -
Since commit 3a01d0ee2b99 ("crypto: skcipher - Remove top-level
givcipher interface"), crypto_grab_skcipher2() and
crypto_grab_skcipher() are equivalent. So switch callers of
crypto_grab_skcipher2() to crypto_grab_skcipher() and remove it.Signed-off-by: Eric Biggers
Signed-off-by: Herbert Xu
25 Oct, 2016
1 commit
-
Fix to return error code -EINVAL from the invalid alg ivsize error
handling case instead of 0, as done elsewhere in this function.Signed-off-by: Wei Yongjun
Signed-off-by: Herbert Xu
02 Oct, 2016
1 commit
-
The cipher block size for GCM is 16 bytes, and thus the CTR transform
used in crypto_gcm_setkey() will also expect a 16-byte IV. However,
the code currently reserves only 8 bytes for the IV, causing
an out-of-bounds access in the CTR transform. This patch fixes
the issue by setting the size of the IV buffer to 16 bytes.Fixes: 84c911523020 ("[CRYPTO] gcm: Add support for async ciphers")
Signed-off-by: Ondrej Mosnacek
Signed-off-by: Herbert Xu
18 Jul, 2016
1 commit
-
This patch converts gcm to use the new skcipher interface as opposed
to ablkcipher.Signed-off-by: Herbert Xu
20 Jun, 2016
1 commit
-
As it is if you ask for a sync gcm you may actually end up with
an async one because it does not filter out async implementations
of ghash.This patch fixes this by adding the necessary filter when looking
for ghash.Cc: stable@vger.kernel.org
Signed-off-by: Herbert Xu
03 Sep, 2015
1 commit
-
Pull SG updates from Jens Axboe:
"This contains a set of scatter-gather related changes/fixes for 4.3:- Add support for limited chaining of sg tables even for
architectures that do not set ARCH_HAS_SG_CHAIN. From Christoph.- Add sg chain support to target_rd. From Christoph.
- Fixup open coded sg->page_link in crypto/omap-sham. From
Christoph.- Fixup open coded crypto ->page_link manipulation. From Dan.
- Also from Dan, automated fixup of manual sg_unmark_end()
manipulations.- Also from Dan, automated fixup of open coded sg_phys()
implementations.- From Robert Jarzmik, addition of an sg table splitting helper that
drivers can use"* 'for-4.3/sg' of git://git.kernel.dk/linux-block:
lib: scatterlist: add sg splitting function
scatterlist: use sg_phys()
crypto/omap-sham: remove an open coded access to ->page_link
scatterlist: remove open coded sg_unmark_end instances
crypto: replace scatterwalk_sg_chain with sg_chain
target/rd: always chain S/G list
scatterlist: allow limited chaining without ARCH_HAS_SG_CHAIN
17 Aug, 2015
2 commits
-
Signed-off-by: Dan Williams
[hch: split from a larger patch by Dan]
Signed-off-by: Christoph Hellwig
Acked-by: Herbert Xu
Signed-off-by: Jens Axboe -
This patch removes the CRYPTO_ALG_AEAD_NEW flag now that everyone
has been converted.Signed-off-by: Herbert Xu
14 Jul, 2015
1 commit
-
This patch converts rfc4106 to the new calling convention where
the IV is now part of the AD and needs to be skipped. This patch
also makes use of the new type-safe way of freeing instances.Signed-off-by: Herbert Xu
17 Jun, 2015
1 commit
-
This patch converts generic gcm and its associated transforms to
the new AEAD interface. The biggest reward is in code reduction
for rfc4543 where it used to do IV stitching which is no longer
needed as the IV is already part of the AD on input.Signed-off-by: Herbert Xu
22 May, 2015
1 commit
-
This patch makes gcm use the default null skcipher instead of
allocating a new one for each tfm.Signed-off-by: Herbert Xu
13 May, 2015
1 commit
-
This patch uses the crypto_aead_set_reqsize helper to avoid directly
touching the internals of aead.Signed-off-by: Herbert Xu
26 Nov, 2014
1 commit
-
This adds the module loading prefix "crypto-" to the template lookup
as well.For example, attempting to load 'vfat(blowfish)' via AF_ALG now correctly
includes the "crypto-" prefix at every level, correctly rejecting "vfat":net-pf-38
algif-hash
crypto-vfat(blowfish)
crypto-vfat(blowfish)-all
crypto-vfatReported-by: Mathias Krause
Signed-off-by: Kees Cook
Acked-by: Mathias Krause
Signed-off-by: Herbert Xu
24 Nov, 2014
1 commit
-
This prefixes all crypto module loading with "crypto-" so we never run
the risk of exposing module auto-loading to userspace via a crypto API,
as demonstrated by Mathias Krause:https://lkml.org/lkml/2013/3/4/70
Signed-off-by: Kees Cook
Signed-off-by: Herbert Xu
01 Aug, 2014
1 commit
-
Change formal parameters to not clash with global names to
eliminate many W=2 warnings.Signed-off-by: Mark Rustad
Signed-off-by: Jeff Kirsher
Signed-off-by: Herbert Xu
07 Oct, 2013
1 commit
-
When comparing MAC hashes, AEAD authentication tags, or other hash
values in the context of authentication or integrity checking, it
is important not to leak timing information to a potential attacker,
i.e. when communication happens over a network.Bytewise memory comparisons (such as memcmp) are usually optimized so
that they return a nonzero value as soon as a mismatch is found. E.g,
on x86_64/i5 for 512 bytes this can be ~50 cyc for a full mismatch
and up to ~850 cyc for a full match (cold). This early-return behavior
can leak timing information as a side channel, allowing an attacker to
iteratively guess the correct result.This patch adds a new method crypto_memneq ("memory not equal to each
other") to the crypto API that compares memory areas of the same length
in roughly "constant time" (cache misses could change the timing, but
since they don't reveal information about the content of the strings
being compared, they are effectively benign). Iow, best and worst case
behaviour take the same amount of time to complete (in contrast to
memcmp).Note that crypto_memneq (unlike memcmp) can only be used to test for
equality or inequality, NOT for lexicographical order. This, however,
is not an issue for its use-cases within the crypto API.We tried to locate all of the places in the crypto API where memcmp was
being used for authentication or integrity checking, and convert them
over to crypto_memneq.crypto_memneq is declared noinline, placed in its own source file,
and compiled with optimizations that might increase code size disabled
("Os") because a smart compiler (or LTO) might notice that the return
value is always compared against zero/nonzero, and might then
reintroduce the same early-return optimization that we are trying to
avoid.Using #pragma or __attribute__ optimization annotations of the code
for disabling optimization was avoided as it seems to be considered
broken or unmaintained for long time in GCC [1]. Therefore, we work
around that by specifying the compile flag for memneq.o directly in
the Makefile. We found that this seems to be most appropriate.As we use ("Os"), this patch also provides a loop-free "fast-path" for
frequently used 16 byte digests. Similarly to kernel library string
functions, leave an option for future even further optimized architecture
specific assembler implementations.This was a joint work of James Yonan and Daniel Borkmann. Also thanks
for feedback from Florian Weimer on this and earlier proposals [2].[1] http://gcc.gnu.org/ml/gcc/2012-07/msg00211.html
[2] https://lkml.org/lkml/2013/2/10/131Signed-off-by: James Yonan
Signed-off-by: Daniel Borkmann
Cc: Florian Weimer
Signed-off-by: Herbert Xu
03 May, 2013
1 commit
-
Pull crypto update from Herbert Xu:
- XTS mode optimisation for twofish/cast6/camellia/aes on x86
- AVX2/x86_64 implementation for blowfish/twofish/serpent/camellia
- SSSE3/AVX/AVX2 optimisations for sha256/sha512
- Added driver for SAHARA2 crypto accelerator
- Fix for GMAC when used in non-IPsec secnarios
- Added generic CMAC implementation (including IPsec glue)
- IP update for crypto/atmel
- Support for more than one device in hwrng/timeriomem
- Added Broadcom BCM2835 RNG driver
- Misc fixes
* git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: (59 commits)
crypto: caam - fix job ring cleanup code
crypto: camellia - add AVX2/AES-NI/x86_64 assembler implementation of camellia cipher
crypto: serpent - add AVX2/x86_64 assembler implementation of serpent cipher
crypto: twofish - add AVX2/x86_64 assembler implementation of twofish cipher
crypto: blowfish - add AVX2/x86_64 implementation of blowfish cipher
crypto: tcrypt - add async cipher speed tests for blowfish
crypto: testmgr - extend camellia test-vectors for camellia-aesni/avx2
crypto: aesni_intel - fix Kconfig problem with CRYPTO_GLUE_HELPER_X86
crypto: aesni_intel - add more optimized XTS mode for x86-64
crypto: x86/camellia-aesni-avx - add more optimized XTS code
crypto: cast6-avx: use new optimized XTS code
crypto: x86/twofish-avx - use optimized XTS code
crypto: x86 - add more optimized XTS-mode for serpent-avx
xfrm: add rfc4494 AES-CMAC-96 support
crypto: add CMAC support to CryptoAPI
crypto: testmgr - add empty test vectors for null ciphers
crypto: testmgr - add AES GMAC test vectors
crypto: gcm - fix rfc4543 to handle async crypto correctly
crypto: gcm - make GMAC work when dst and src are different
hwrng: timeriomem - added devicetree hooks
...
25 Apr, 2013
2 commits
-
If the gcm cipher used by rfc4543 does not complete request immediately,
the authentication tag is not copied to destination buffer. Patch adds
correct async logic for this case.Signed-off-by: Jussi Kivilinna
Signed-off-by: Herbert Xu -
The GMAC code assumes that dst==src, which causes problems when trying to add
rfc4543(gcm(aes)) test vectors.So fix this code to work when source and destination buffer are different.
Signed-off-by: Jussi Kivilinna
Signed-off-by: Herbert Xu
