| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Remove the bitlocker cipher which is not supported by
the kernel.
Signed-off-by: Gilad Ben-Yossef <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
Remove the implementaion of automatic advancement of sector size in IV for
storage ciphers as its use is not supproted by the kernel.
Signed-off-by: Gilad Ben-Yossef <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
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.
[[email protected]: fs/crypto/inline_crypt.c needs linux/slab.h]
[[email protected]: fix fs/crypto/inline_crypt.c some more]
Suggested-by: Joe Perches <[email protected]>
Signed-off-by: Waiman Long <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Acked-by: David Howells <[email protected]>
Acked-by: Michal Hocko <[email protected]>
Acked-by: Johannes Weiner <[email protected]>
Cc: Jarkko Sakkinen <[email protected]>
Cc: James Morris <[email protected]>
Cc: "Serge E. Hallyn" <[email protected]>
Cc: Joe Perches <[email protected]>
Cc: Matthew Wilcox <[email protected]>
Cc: David Rientjes <[email protected]>
Cc: Dan Carpenter <[email protected]>
Cc: "Jason A . Donenfeld" <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Linus Torvalds <[email protected]>
|
|
Remove yet another unused field left over from times gone by.
Signed-off-by: Gilad Ben-Yossef <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
The ESSIV support in ccree was added before the kernel
generic support and using a slightly different API.
Brings the ccree essiv interface into compliance with
kernel crypto api one.
Since CryptoCell only support 256 bit AES key for ESSIV,
also use a fallback if requested a smaller key size.
Signed-off-by: Gilad Ben-Yossef <[email protected]>
Cc: Ard Biesheuvel <[email protected]>
Cc: Libo Wang <[email protected]>
Cc: Markus Elfring <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
Fix a small resource leak on the error path of cipher processing.
Signed-off-by: Gilad Ben-Yossef <[email protected]>
Fixes: 63ee04c8b491e ("crypto: ccree - add skcipher support")
Cc: Markus Elfring <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
Instead of manually allocating a 'struct shash_desc' on the stack and
calling crypto_shash_digest(), switch to using the new helper function
crypto_shash_tfm_digest() which does this for us.
Cc: Gilad Ben-Yossef <[email protected]>
Signed-off-by: Eric Biggers <[email protected]>
Acked-by: Gilad Ben-Yossef <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
Remove left over ancient and now misleading TODO remarks.
Signed-off-by: Gilad Ben-Yossef <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
As the lifetime of the cipher data matches the lifetime of the driver,
cipher data can be allocated using the managed allocators.
Signed-off-by: Geert Uytterhoeven <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
As the lifetime of the AEAD data matches the lifetime of the driver,
AEAD data can be allocated using the managed allocators.
While at it, simplify cc_aead_free() by removing an unneeded cast, and
an unneeded check (aead_handle is always valid here).
Signed-off-by: Geert Uytterhoeven <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
The cc_cipher_handle structure contains only a single member, and only
one instance exists. Simplify the code and reduce memory consumption by
moving this member to struct cc_drvdata.
Signed-off-by: Geert Uytterhoeven <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
SRAM addresses are small integer offsets into local SRAM. Currently
they are stored using a mixture of cc_sram_addr_t (u64), u32, and
dma_addr_t types.
Settle on u32, and remove the cc_sram_addr_t typedefs.
This allows to drop several casts.
Signed-off-by: Geert Uytterhoeven <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
Unneeded casts prevent the compiler from performing valuable checks.
This is especially true for function pointers.
Remove these casts, to prevent silently introducing bugs when a
variable's type might be changed in the future.
No change in generated code.
Signed-off-by: Geert Uytterhoeven <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/crypto/ccree/cc_cipher.c: In function 'cc_setup_state_desc':
drivers/crypto/ccree/cc_cipher.c:536:15: warning:
variable 'du_size' set but not used [-Wunused-but-set-variable]
commit 5c83e8ec4d51 ("crypto: ccree - fix FDE descriptor sequence")
involved this unused variable, so remove it.
Reported-by: Hulk Robot <[email protected]>
Signed-off-by: YueHaibing <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
OFB and CTR modes block sizes were wrongfully reported as
the underlying block sizes. Fix it to 1 bytes as they
turn the block ciphers into stream ciphers.
Also document why our XTS differes from the generic
implementation.
Signed-off-by: Gilad Ben-Yossef <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
In FDE mode (xts, essiv and bitlocker) the cryptocell hardware requires
that the the XEX key will be loaded after Key1.
Signed-off-by: Ofir Drang <[email protected]>
Cc: [email protected]
Signed-off-by: Herbert Xu <[email protected]>
|
|
We have several loud error log messages that are already reported
via the normal return code mechanism and produce a lot of noise
when the new testmgr extra test are enabled. Turn these into
debug only messages
Signed-off-by: Gilad Ben-Yossef <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Horia Geantă <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
The ccree driver does not use the ablkcipher interface but contains
a rudimentary reference to it in the naming of an unrelated macro.
Let's rename it to avoid confusion.
Acked-by: Gilad Ben-Yossef <[email protected]>
Signed-off-by: Ard Biesheuvel <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
In XTS encryption/decryption the plaintext byte size
can be >= AES_BLOCK_SIZE. This patch enable the AES-XTS ciphertext
stealing implementation in ccree driver.
Signed-off-by: Uri Shir <[email protected]>
Acked-by: Gilad Ben-Yossef <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
Signed-off-by: Ard Biesheuvel <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/crypto/ccree/cc_cipher.c: In function cc_setup_key_desc:
drivers/crypto/ccree/cc_cipher.c:645:15: warning: variable du_size set but not used [-Wunused-but-set-variable]
It is never used since introduction in
commit dd8486c75085 ("crypto: ccree - move key load desc. before flow desc.")
Signed-off-by: YueHaibing <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
There is a spelling mistake in a dev_dbg message, fix it.
Signed-off-by: Colin Ian King <[email protected]>
Acked-By: Gilad Ben-Yossef <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
This sacrificial copyright header update is offered to the legal department
as atonement for any changes made in this driver files in the course of
the current year which have not been duly recorded as such.
Signed-off-by: Gilad Ben-Yossef <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
We were doing backlog notification callbacks via a cipher/hash/aead
request structure cast to the base structure, which may or may not
work based on how the structure is laid in memory and is not safe.
Fix it by delegating the backlog notification to the appropriate
internal callbacks which are type aware.
Signed-off-by: Gilad Ben-Yossef <[email protected]>
Cc: [email protected] # v4.19+
Signed-off-by: Herbert Xu <[email protected]>
|
|
We were computing the next IV in software instead of reading it from HW
on the premise that this can be quicker due to the small size of IVs but
this proved to be much more hassle and bug ridden than expected.
Move to reading the next IV as computed by the HW.
This fixes a number of issue with next IV being wrong for OFB, CTS-CBC
and probably most of the other ciphers as well.
Signed-off-by: Gilad Ben-Yossef <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
Adapt the CPP descriptor to new HW interface.
Signed-off-by: Gilad Ben-Yossef <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
Add the registration for the SM4 based policy protected keys ciphers.
Signed-off-by: Gilad Ben-Yossef <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
Add the missing logic to set usage policy protections for keys.
This enables key policy protection for AES.
Signed-off-by: Gilad Ben-Yossef <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
Add support for the Security Disabled mode under which only
pure cryptographic functionality is enabled and protected keys
services are unavailable.
Signed-off-by: Gilad Ben-Yossef <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
Refactor to move the descriptor copying the MLLI line to SRAM
to before the key loading descriptor in preparation to the
introduction of CPP later on.
Signed-off-by: Gilad Ben-Yossef <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
Refactor the descriptor setup code in order to move the key loading
descriptor to one before last position. This has no effect on current
functionality but is needed for later support of Content Protection
Policy keys.
Signed-off-by: Gilad Ben-Yossef <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
Building with clang for a 32-bit architecture runs over the stack
frame limit in the setkey function:
drivers/crypto/ccree/cc_cipher.c:318:12: error: stack frame size of 1152 bytes in function 'cc_cipher_setkey' [-Werror,-Wframe-larger-than=]
The problem is that there are two large variables: the temporary
'tmp' array and the SHASH_DESC_ON_STACK() declaration. Moving
the first into the block in which it is used reduces the
total frame size to 768 bytes, which seems more reasonable
and is under the warning limit.
Fixes: 63ee04c8b491 ("crypto: ccree - add skcipher support")
Signed-off-by: Arnd Bergmann <[email protected]>
Acked-By: Gilad Ben-Yossef <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
Add missing break statement in order to prevent the code from falling
through to case S_DIN_to_DES.
This bug was found thanks to the ongoing efforts to enable
-Wimplicit-fallthrough.
Fixes: 63ee04c8b491 ("crypto: ccree - add skcipher support")
Cc: [email protected]
Signed-off-by: Gustavo A. R. Silva <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
For decryption in CBC mode we need to save the last ciphertext block
for use as the next IV. However, we were trying to do this also with
zero sized ciphertext resulting in a panic.
Fix this by only doing the copy if the ciphertext length is at least
of IV size.
Signed-off-by: Gilad Ben-Yossef <[email protected]>
Cc: [email protected]
Signed-off-by: Herbert Xu <[email protected]>
|
|
We were copying the last ciphertext block into the IV field
for CBC before removing the DMA mapping of the output buffer
with the result of the buffer sometime being out-of-sync cache
wise and were getting intermittent cases of bad output IV.
Fix it by moving the DMA buffer unmapping before the copy.
Signed-off-by: Gilad Ben-Yossef <[email protected]>
Fixes: 00904aa0cd59 ("crypto: ccree - fix iv handling")
Cc: <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
Add support for Arm TrustZone CryptoCell 703.
The 703 is a variant of the CryptoCell 713 that supports only
algorithms certified by the Chinesse Office of the State Commercial
Cryptography Administration (OSCCA).
Signed-off-by: Gilad Ben-Yossef <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
Add support for SM4 cipher in CryptoCell 713.
Signed-off-by: Gilad Ben-Yossef <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
The ccree driver had a sanity check that we are not asked
to encrypt an XTS buffer bigger than a sane sector size
since XTS IV needs to include the sector number in the IV
so this is not expected in any real use case.
Unfortunately, this breaks cryptsetup benchmark test which
has a synthetic performance test using 64k buffer of data
with the same IV.
Remove the sanity check and allow the user to hang themselves
and/or run benchmarks if they so wish.
Reported-by: Geert Uytterhoeven <[email protected]>
Signed-off-by: Gilad Ben-Yossef <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
In certain error path req_ctx->iv was being freed despite
not being allocated because it was not initialized to NULL.
Rather than play whack a mole with the structure various
field, zero it before use.
This fixes a kernel panic that may occur if an invalid
buffer size was requested triggering the bug above.
Fixes: 63ee04c8b491 ("crypto: ccree - add skcipher support")
Reported-by: Geert Uytterhoeven <[email protected]>
Signed-off-by: Gilad Ben-Yossef <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
IV generation is not available via the skcipher interface.
Remove the left over support of it from the ablkcipher days.
Signed-off-by: Gilad Ben-Yossef <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
Drop the explicit setting of CRYPTO_ALG_TYPE_AEAD or
CRYPTO_ALG_TYPE_SKCIPHER flags during alg registration as they are
set anyway by the framework.
Signed-off-by: Gilad Ben-Yossef <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
The ccree driver implemented NIST 800-38A CBC-CS2 ciphertext format,
which only reverses the last two blocks if the stolen ciphertext amount
are none zero. Move it to the kernel chosen format of CBC-CS3 which swaps
the final blocks unconditionally and rename it to "cts" now that it
complies with the kernel format and passes the self tests.
Ironically, the CryptoCell REE HW does just that, so the fix is dropping
the code that forced it to use plain CBC if the ciphertext was block
aligned.
Signed-off-by: Gilad Ben-Yossef <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
Remove legacy code no longer used by anything.
Signed-off-by: Gilad Ben-Yossef <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
We were copying our last cipher block into the request for use as IV for
all modes of operations. Fix this by discerning the behaviour based on
the mode of operation used: copy ciphertext for CBC, update counter for
CTR.
CC: [email protected]
Fixes: 63ee04c8b491 ("crypto: ccree - add skcipher support")
Reported by: Hadar Gat <[email protected]>
Signed-off-by: Gilad Ben-Yossef <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
Some skcipher algorithms set .cra_flags = CRYPTO_ALG_TYPE_SKCIPHER. But
this is redundant with the C structure type ('struct skcipher_alg'), and
crypto_register_skcipher() already sets the type flag automatically,
clearing any type flag that was already there. Apparently the useless
assignment has just been copy+pasted around.
So, remove the useless assignment from all the skcipher algorithms.
This patch shouldn't change any actual behavior.
Signed-off-by: Eric Biggers <[email protected]>
Acked-by: Gilad Ben-Yossef <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
Enable CryptoCell support for hardware keys.
Hardware keys are regular AES keys loaded into CryptoCell internal memory
via firmware, often from secure boot ROM or hardware fuses at boot time.
As such, they can be used for enc/dec purposes like any other key but
cannot (read: extremely hard to) be extracted since since they are not
available anywhere in RAM during runtime.
The mechanism has some similarities to s390 secure keys although the keys
are not wrapped or sealed, but simply loaded offline. The interface was
therefore modeled based on the s390 secure keys support.
Signed-off-by: Gilad Ben-Yossef <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
Add support for the legacy CryptoCell 630 and 710 revs.
Signed-off-by: Gilad Ben-Yossef <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|