- 19 Jan, 2018 1 commit
-
-
Harsh Jain authored
Fix Warning introduced in changeset e1a018e6 ("crypto: chelsio - Remove dst sg size zero check") Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
Harsh Jain <harsh@chelsio.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
- 18 Jan, 2018 19 commits
-
-
Ard Biesheuvel authored
Load the four SHA-1 round constants using immediates rather than literal pool entries, to avoid having executable data that may be exploitable under speculation attacks. Signed-off-by:
Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by:
-
Ard Biesheuvel authored
Move the SHA2 round constant table to the .rodata section where it is safe from being exploited by speculative execution. Signed-off-by:
-
Ard Biesheuvel authored
Move the CRC-T10DIF literal data to the .rodata section where it is safe from being exploited by speculative execution. Signed-off-by:
-
Ard Biesheuvel authored
Move CRC32 literal data to the .rodata section where it is safe from being exploited by speculative execution. Signed-off-by:
-
Ard Biesheuvel authored
Move the S-boxes and some other literals to the .rodata section where it is safe from being exploited by speculative execution. Signed-off-by:
-
Ard Biesheuvel authored
Move the AES inverse S-box to the .rodata section where it is safe from abuse by speculation. Signed-off-by:
-
Martin Kaiser authored
Use the SIMPLE_DEV_PM_OPS() macro instead of populating a struct dev_pm_ops directly. The suspend and resume functions will now be used for both hibernation and suspend to ram. If power management is disabled, SIMPLE_DEV_PM_OPS() evaluates to nothing, The two functions won't be used and won't be included in the kernel. Mark them as __maybe_unused to clarify that this is intended behaviour. With these modifications in place, we don't need the #ifdefs for power management any more. Signed-off-by:
Martin Kaiser <martin@kaiser.cx> Signed-off-by:
-
Harsh Jain authored
sg_nents_xlen will take care of zero length sg list. Remove Destination sg list size zero check. Signed-off-by:
-
Harsh Jain authored
Add ctr and sha combination of algo in authenc mode. Signed-off-by:
-
Harsh Jain authored
Skip decrypt operation on IV received from HW for last request. Signed-off-by:
-
Harsh Jain authored
Add warning message if sg is NULL after skipping bytes. Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Harsh Jain authored
Fix inconsistent Indenting. Reported-by:
-
Robin Murphy authored
phys_to_dma() is an internal helper for certain DMA API implementations, and is not appropriate for drivers to use. It appears that what the CESA driver really wants to be using is dma_map_resource() - admittedly that didn't exist when the offending code was first merged, but it does now. Signed-off-by:
Robin Murphy <robin.murphy@arm.com> Acked-by:
Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by:
-
weiyongjun \(A\) authored
There is a error message within devm_ioremap_resource already, so remove the dev_err call to avoid redundant error message. Signed-off-by:
Wei Yongjun <weiyongjun1@huawei.com> Reviewed-by:
Krzysztof Kozlowski <krzk@kernel.org> Acked-by:
Łukasz Stelmach <l.stelmach@samsung.com> Signed-off-by:
-
Dan Carpenter authored
"val" needs to be signed for the error handling to work. Fixes: 6cd225cc ("hwrng: exynos - add Samsung Exynos True RNG driver") Signed-off-by:
-
Sean Wang authored
When hw_random device's quality is non-zero, it will automatically fill the kernel's entropy pool at boot. For the purpose, one conservative quality value is being picked up as the default value. Signed-off-by:
Sean Wang <sean.wang@mediatek.com> Signed-off-by:
-
Ard Biesheuvel authored
Implement the SHA-512 using the new special instructions that have been introduced as an optional extension in ARMv8.2. Signed-off-by:
Steve Capper <steve.capper@arm.com> Signed-off-by:
-
Krzysztof Kozlowski authored
Replace GPL license statement with SPDX GPL-2.0 license identifier. Signed-off-by:
-
Krzysztof Kozlowski authored
Replace GPL license statement with SPDX GPL-2.0 license identifier and correct the module license to GPLv2. The license itself was a generic GPL because of copy-and-paste from old drivers/char/hw_random/exynos-rng.c driver (on which this was based on). However the module license indicated GPL-2.0 or later. GPL-2.0 was intended by author so fix up this mess. Signed-off-by:
-
- 14 Jan, 2018 1 commit
-
-
Antoine Tenart authored
This patch adds the SafeXcel EIP97 compatible to the Inside Secure device tree bindings documentation. Signed-off-by:
Antoine Tenart <antoine.tenart@free-electrons.com> Signed-off-by:
-
- 12 Jan, 2018 19 commits
-
-
tcharding authored
SPHINX build emits multiple warnings of kind: warning: duplicate section name 'Note' (when building kernel via make target 'htmldocs') This is caused by repeated use of comments of form: * Note: soau soaeusoa uoe We can change the format without loss of clarity and clear the build warnings. Add '**[mandatory]**' or '**[optional]**' as kernel-doc field element description prefix This renders in HTML as (prefixes in bold) final [mandatory] Retrieve result from the driver. This function finalizes the transformation and retrieves the resulting hash from the driver and pushes it back to upper layers. No data processing happens at this point unless hardware requires it to finish the transformation (then the data buffered by the device driver is processed). Signed-off-by:Tobin C. Harding <me@tobin.cc> Signed-off-by:
-
Eric Biggers authored
Convert salsa20-asm from the deprecated "blkcipher" API to the "skcipher" API, in the process fixing it up to use the generic helpers. This allows removing the salsa20_keysetup() and salsa20_ivsetup() assembly functions, which aren't performance critical; the C versions do just fine. This also fixes the same bug that salsa20-generic had, where the state array was being maintained directly in the transform context rather than on the stack or in the request context. Thus, if multiple threads used the same Salsa20 transform concurrently they produced the wrong results. Signed-off-by:
Eric Biggers <ebiggers@google.com> Signed-off-by:
-
Eric Biggers authored
Export the Salsa20 constants, transform context, and initialization functions so that they can be reused by the x86 implementation. Signed-off-by:
-
Eric Biggers authored
Convert salsa20-generic from the deprecated "blkcipher" API to the "skcipher" API, in the process fixing it up to be thread-safe (as the crypto API expects) by maintaining each request's state separately from the transform context. Also remove the unnecessary cra_alignmask and tighten validation of the key size by accepting only 16 or 32 bytes, not anything in between. These changes bring the code close to the way chacha20-generic does things, so hopefully it will be easier to maintain in the future. However, the way Salsa20 interprets the IV is still slightly different; that was not changed. Signed-off-by:
-
Arnd Bergmann authored
While testing other changes, I discovered that gcc-7.2.1 produces badly optimized code for aes_encrypt/aes_decrypt. This is especially true when CONFIG_UBSAN_SANITIZE_ALL is enabled, where it leads to extremely large stack usage that in turn might cause kernel stack overflows: crypto/aes_generic.c: In function 'aes_encrypt': crypto/aes_generic.c:1371:1: warning: the frame size of 4880 bytes is larger than 2048 bytes [-Wframe-larger-than=] crypto/aes_generic.c: In function 'aes_decrypt': crypto/aes_generic.c:1441:1: warning: the frame size of 4864 bytes is larger than 2048 bytes [-Wframe-larger-than=] I verified that this problem exists on all architectures that are supported by gcc-7.2, though arm64 in particular is less affected than the others. I also found that gcc-7.1 and gcc-8 do not show the extreme stack usage but still produce worse code than earlier versions for this file, apparently because of optimization passes that generally provide a substantial improvement in object code quality but understandably fail to find any shortcuts in the AES algorithm. Possible workarounds include a) disabling -ftree-pre and -ftree-sra optimizations, this was an earlier patch I tried, which reliably fixed the stack usage, but caused a serious performance regression in some versions, as later testing found. b) disabling UBSAN on this file or all ciphers, as suggested by Ard Biesheuvel. This would lead to massively better crypto performance in UBSAN-enabled kernels and avoid the stack usage, but there is a concern over whether we should exclude arbitrary files from UBSAN at all. c) Forcing the optimization level in a different way. Similar to a), but rather than deselecting specific optimization stages, this now uses "gcc -Os" for this file, regardless of the CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE/SIZE option. This is a reliable workaround for the stack consumption on all architecture, and I've retested the performance results now on x86, cycles/byte (lower is better) for cbc(aes-generic) with 256 bit keys: -O2 -Os gcc-6.3.1 14.9 15.1 gcc-7.0.1 14.7 15.3 gcc-7.1.1 15.3 14.7 gcc-7.2.1 16.8 15.9 gcc-8.0.0 15.5 15.6 This implements the option c) by enabling forcing -Os on all compiler versions starting with gcc-7.1. As a workaround for PR83356, it would only be needed for gcc-7.2+ with UBSAN enabled, but since it also shows better performance on gcc-7.1 without UBSAN, it seems appropriate to use the faster version here as well. Side note: during testing, I also played with the AES code in libressl, which had a similar performance regression from gcc-6 to gcc-7.2, but was three times slower overall. It might be interesting to investigate that further and possibly port the Linux implementation into that. Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83356 Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83651 Cc: Richard Biener <rguenther@suse.de> Cc: Jakub Jelinek <jakub@gcc.gnu.org> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Acked-by:
-
Eric Biggers authored
Similar to what was done for the hash API, update the AEAD API to track whether each transform has been keyed, and reject encryption/decryption if a key is needed but one hasn't been set. This isn't quite as important as the equivalent fix for the hash API because AEADs always require a key, so are unlikely to be used without one. Still, tracking the key will prevent accidental unkeyed use. algif_aead also had to track the key anyway, so the new flag replaces that and slightly simplifies the algif_aead implementation. Signed-off-by:
-
Eric Biggers authored
Similar to what was done for the hash API, update the skcipher API to track whether each transform has been keyed, and reject encryption/decryption if a key is needed but one hasn't been set. This isn't as important as the equivalent fix for the hash API because symmetric ciphers almost always require a key (the "null cipher" is the only exception), so are unlikely to be used without one. Still, tracking the key will prevent accidental unkeyed use. algif_skcipher also had to track the key anyway, so the new flag replaces that and simplifies the algif_skcipher implementation. Signed-off-by:
-
Eric Biggers authored
Now that the crypto API prevents a keyed hash from being used without setting the key, there's no need for GHASH to do this check itself. Signed-off-by:
-
Eric Biggers authored
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 <syzkaller@googlegroups.com> Cc: stable@vger.kernel.org Signed-off-by:
-
Eric Biggers authored
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 authored
Since Poly1305 requires a nonce per invocation, the Linux kernel implementations of Poly1305 don't use the crypto API's keying mechanism and instead expect the key and nonce as the first 32 bytes of the data. But ->setkey() is still defined as a stub returning an error code. This prevents Poly1305 from being used through AF_ALG and will also break it completely once we start enforcing that all crypto API users (not just AF_ALG) call ->setkey() if present. Fix it by removing crypto_poly1305_setkey(), leaving ->setkey as NULL. Cc: stable@vger.kernel.org Signed-off-by:
-
Eric Biggers authored
When the mcryptd template is used to wrap an unkeyed hash algorithm, don't install a ->setkey() method to the mcryptd instance. This change is necessary for mcryptd to keep working with unkeyed hash algorithms once we start enforcing that ->setkey() is called when present. Cc: stable@vger.kernel.org Signed-off-by:
-
Eric Biggers authored
When the cryptd template is used to wrap an unkeyed hash algorithm, don't install a ->setkey() method to the cryptd instance. This change is necessary for cryptd to keep working with unkeyed hash algorithms once we start enforcing that ->setkey() is called when present. Cc: stable@vger.kernel.org Signed-off-by:
-
Eric Biggers authored
Templates that use an shash spawn can use crypto_shash_alg_has_setkey() to determine whether the underlying algorithm requires a key or not. But there was no corresponding function for ahash spawns. Add it. Note that the new function actually has to support both shash and ahash algorithms, since the ahash API can be used with either. Cc: stable@vger.kernel.org Signed-off-by:
-
Colin Ian King authored
There seems to be a cut-n-paste bug with the name of the buffer being free'd, xoutbuf should be used instead of axbuf. Detected by CoverityScan, CID#1463420 ("Copy-paste error") Fixes: 427988d9 ("crypto: tcrypt - add multibuf aead speed test") Signed-off-by:Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Colin Ian King authored
Trivial fix to spelling mistakes in pr_err error message text. Signed-off-by:
-
Stephan Mueller authored
The user space interface allows specifying the type and mask field used to allocate the cipher. Only a subset of the possible flags are intended for user space. Therefore, white-list the allowed flags. In case the user space caller uses at least one non-allowed flag, EINVAL is returned. Reported-by:
Stephan Mueller <smueller@chronox.de> Signed-off-by:
-
Joey Pabalinas authored
When char is signed, storing the values 0xba (186) and 0xad (173) in the `guard` array produces signed overflow. Change the type of `guard` to static unsigned char to correct undefined behavior and reduce function stack usage. Signed-off-by:
Joey Pabalinas <joeypabalinas@gmail.com> Signed-off-by:
-
Eric Biggers authored
For chacha20_block(), use the existing 32-bit left-rotate function instead of defining one ourselves. Signed-off-by:
-
