- 01 Nov, 2023 1 commit
-
-
Eric Biggers authored
alg_test_descs[] needs to be in sorted order, since it is used for binary search. This fixes the following boot-time warning: testmgr: alg_test_descs entries in wrong order: 'pkcs1pad(rsa,sha512)' before 'pkcs1pad(rsa,sha3-256)' Fixes: ee62afb9 ("crypto: rsa-pkcs1pad - Add FIPS 202 SHA-3 support") Signed-off-by:Eric Biggers <ebiggers@google.com> Reviewed-by:
Dimitri John Ledkov <dimitri.ledkov@canonical.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
- 27 Oct, 2023 39 commits
-
-
Dimitri John Ledkov authored
Update the documentation to mention that ECC NIST P-384 automatic keypair generation is available to use ECDSA signature type, in addition to the RSA. Drop mentions of the now removed SHA-1 and SHA-224 options. Add the just added FIPS 202 SHA-3 module signature hashes. Signed-off-by:
-
Dimitri John Ledkov authored
Add Kconfig options to use SHA-3 for kernel module signing. 256 size for RSA only, and higher sizes for RSA and NIST P-384. Signed-off-by:
-
Dimitri John Ledkov authored
Add FIPS 202 SHA-3 hash signature support in x509 certificates, pkcs7 signatures, and authenticode signatures. Supports hashes of size 256 and up, as 224 is too weak for any practical purposes. Signed-off-by:
-
Dimitri John Ledkov authored
Add support in rsa-pkcs1pad for FIPS 202 SHA-3 hashes, sizes 256 and up. As 224 is too weak for any practical purposes. Signed-off-by:
-
Dimitri John Ledkov authored
Register FIPS 202 SHA-3 hashes in hash info for IMA and other users. Sizes 256 and up, as 224 is too weak for any practical purposes. Signed-off-by:
-
Dimitri John Ledkov authored
Add OID for FIPS 202 SHA-3 family of hash functions, RSA & ECDSA signatures using those. Limit to 256 or larger sizes, for interoperability reasons. 224 is too weak for any practical uses. Signed-off-by:
-
Eric Biggers authored
The "ahash" API provides access to both CPU-based and hardware offload- based implementations of hash algorithms. Typically the former are implemented as "shash" algorithms under the hood, while the latter are implemented as "ahash" algorithms. The "ahash" API provides access to both. Various kernel subsystems use the ahash API because they want to support hashing hardware offload without using a separate API for it. Yet, the common case is that a crypto accelerator is not actually being used, and ahash is just wrapping a CPU-based shash algorithm. This patch optimizes the ahash API for that common case by eliminating the extra indirect call for each ahash operation on top of shash. It also fixes the double-counting of crypto stats in this scenario (though CONFIG_CRYPTO_STATS should *not* be enabled by anyone interested in performance anyway...), and it eliminates redundant checking of CRYPTO_TFM_NEED_KEY. As a bonus, it also shrinks struct crypto_ahash. Signed-off-by:
-
Eric Biggers authored
Since the previous patch made crypto_shash_type visible to ahash.c, change checks for '->cra_type != &crypto_ahash_type' to '->cra_type == &crypto_shash_type'. This makes more sense and avoids having to forward-declare crypto_ahash_type. The result is still the same, since the type is either shash or ahash here. Signed-off-by:
-
Eric Biggers authored
The functions that are involved in implementing the ahash API on top of an shash algorithm belong better in ahash.c, not in shash.c where they currently are. Move them. Signed-off-by:
-
Eric Biggers authored
The function pointer crypto_ahash::init is an internal implementation detail of the ahash API that exists to help it support both ahash and shash algorithms. With an upcoming refactoring of how the ahash API supports shash algorithms, this field will be removed. Some drivers are invoking crypto_ahash::init to call into their own code, which is unnecessary and inefficient. The talitos driver is one of those drivers. Make it just call its own code directly. Signed-off-by:
-
Eric Biggers authored
The function pointer crypto_ahash::init is an internal implementation detail of the ahash API that exists to help it support both ahash and shash algorithms. With an upcoming refactoring of how the ahash API supports shash algorithms, this field will be removed. Some drivers are invoking crypto_ahash::init to call into their own code, which is unnecessary and inefficient. The chelsio driver is one of those drivers. Make it just call its own code directly. Signed-off-by:
-
Eric Biggers authored
Improve the file comment for crypto/ahash.c. Signed-off-by:
-
Eric Biggers authored
struct ahash_request_priv is unused, so remove it. Signed-off-by:
-
Eric Biggers authored
crypto_ahash_alignmask() no longer has any callers, and it always returns 0 now that neither ahash nor shash algorithms support nonzero alignmasks anymore. Therefore, remove it. Signed-off-by:
-
Eric Biggers authored
Now that the alignmask for ahash and shash algorithms is always 0, simplify crypto_gcm_create_common() accordingly. Signed-off-by:
-
Eric Biggers authored
Now that the alignmask for ahash and shash algorithms is always 0, simplify chachapoly_create() accordingly. Signed-off-by:
-
Eric Biggers authored
Now that the alignmask for ahash and shash algorithms is always 0, simplify crypto_ccm_create_common() accordingly. Signed-off-by:
-
Eric Biggers authored
Now that the alignmask for ahash and shash algorithms is always 0, crypto_ahash_alignmask() always returns 0 and will be removed. In preparation for this, stop checking crypto_ahash_alignmask() in ah6.c. Signed-off-by:
-
Eric Biggers authored
Now that the alignmask for ahash and shash algorithms is always 0, crypto_ahash_alignmask() always returns 0 and will be removed. In preparation for this, stop checking crypto_ahash_alignmask() in ah4.c. Signed-off-by:
-
Eric Biggers authored
Now that the alignmask for ahash and shash algorithms is always 0, crypto_ahash_alignmask() always returns 0 and will be removed. In preparation for this, stop checking crypto_ahash_alignmask() in testmgr. As a result of this change, test_sg_division::offset_relative_to_alignmask and testvec_config::key_offset_relative_to_alignmask no longer have any effect on ahash (or shash) algorithms. Therefore, also stop setting these flags in default_hash_testvec_configs[]. Signed-off-by:
-
Eric Biggers authored
Now that the alignmask for ahash and shash algorithms is always 0, simplify the code in authenc accordingly. Signed-off-by:
-
Eric Biggers authored
Now that the alignmask for ahash and shash algorithms is always 0, simplify the code in authenc accordingly. Signed-off-by:
-
Eric Biggers authored
Currently, the ahash API checks the alignment of all key and result buffers against the algorithm's declared alignmask, and for any unaligned buffers it falls back to manually aligned temporary buffers. This is virtually useless, however. First, since it does not apply to the message, its effect is much more limited than e.g. is the case for the alignmask for "skcipher". Second, the key and result buffers are given as virtual addresses and cannot (in general) be DMA'ed into, so drivers end up having to copy to/from them in software anyway. As a result it's easy to use memcpy() or the unaligned access helpers. The crypto_hash_walk_*() helper functions do use the alignmask to align the message. But with one exception those are only used for shash algorithms being exposed via the ahash API, not for native ahashes, and aligning the message is not required in this case, especially now that alignmask support has been removed from shash. The exception is the n2_core driver, which doesn't set an alignmask. In any case, no ahash algorithms actually set a nonzero alignmask anymore. Therefore, remove support for it from ahash. The benefit is that all the code to handle "misaligned" buffers in the ahash API goes away, reducing the overhead of the ahash API. This follows the same change that was made to shash. Signed-off-by:
-
Eric Biggers authored
The crypto API's support for alignmasks for ahash algorithms is nearly useless, as its only effect is to cause the API to align the key and result buffers. The drivers that happen to be specifying an alignmask for ahash rarely actually need it. When they do, it's easily fixable, especially considering that these buffers cannot be used for DMA. In preparation for removing alignmask support from ahash, this patch makes the stm32 driver no longer use it. This driver didn't actually rely on it; it only writes to the result buffer in stm32_hash_finish(), simply using memcpy(). And stm32_hash_setkey() does not assume any alignment for the key buffer. Signed-off-by:
-
Eric Biggers authored
The crypto API's support for alignmasks for ahash algorithms is nearly useless, as its only effect is to cause the API to align the key and result buffers. The drivers that happen to be specifying an alignmask for ahash rarely actually need it. When they do, it's easily fixable, especially considering that these buffers cannot be used for DMA. In preparation for removing alignmask support from ahash, this patch makes the starfive driver no longer use it. This driver did actually rely on it, but only for storing to the result buffer using int stores in starfive_hash_copy_hash(). This patch makes starfive_hash_copy_hash() use put_unaligned() instead. (It really should use a specific endianness, but that's an existing bug.) Signed-off-by:
-
Eric Biggers authored
The crypto API's support for alignmasks for ahash algorithms is nearly useless, as its only effect is to cause the API to align the key and result buffers. The drivers that happen to be specifying an alignmask for ahash rarely actually need it. When they do, it's easily fixable, especially considering that these buffers cannot be used for DMA. In preparation for removing alignmask support from ahash, this patch makes the rockchip driver no longer use it. This driver didn't actually rely on it; it only writes to the result buffer in rk_hash_run(), already using put_unaligned_le32(). And this driver only supports unkeyed hash algorithms, so the key buffer need not be considered. Signed-off-by:
-
Eric Biggers authored
The crypto API's support for alignmasks for ahash algorithms is nearly useless, as its only effect is to cause the API to align the key and result buffers. The drivers that happen to be specifying an alignmask for ahash rarely actually need it. When they do, it's easily fixable, especially considering that these buffers cannot be used for DMA. In preparation for removing alignmask support from ahash, this patch makes the omap-sham driver no longer use it. This driver did actually rely on it, but only for storing to the result buffer using __u32 stores in omap_sham_copy_ready_hash(). This patch makes omap_sham_copy_ready_hash() use put_unaligned() instead. (It really should use a specific endianness, but that's an existing bug.) Signed-off-by:
-
Eric Biggers authored
The crypto API's support for alignmasks for ahash algorithms is nearly useless, as its only effect is to cause the API to align the key and result buffers. The drivers that happen to be specifying an alignmask for ahash rarely actually need it. When they do, it's easily fixable, especially considering that these buffers cannot be used for DMA. In preparation for removing alignmask support from ahash, this patch makes the talitos driver no longer use it. This driver didn't actually rely on it; it only writes to the result buffer in common_nonsnoop_hash_unmap(), simply using memcpy(). And this driver's "ahash_setkey()" function does not assume any alignment for the key buffer. Signed-off-by:
-
Eric Biggers authored
The crypto API's support for alignmasks for ahash algorithms is nearly useless, as its only effect is to cause the API to align the key and result buffers. The drivers that happen to be specifying an alignmask for ahash rarely actually need it. When they do, it's easily fixable, especially considering that these buffers cannot be used for DMA. In preparation for removing alignmask support from ahash, this patch makes the s5p-sss driver no longer use it. This driver didn't actually rely on it; it only writes to the result buffer in s5p_hash_copy_result(), simply using memcpy(). And this driver only supports unkeyed hash algorithms, so the key buffer need not be considered. Signed-off-by:
-
Eric Biggers authored
The crypto API's support for alignmasks for ahash algorithms is nearly useless, as its only effect is to cause the API to align the key and result buffers. The drivers that happen to be specifying an alignmask for ahash rarely actually need it. When they do, it's easily fixable, especially considering that these buffers cannot be used for DMA. In preparation for removing alignmask support from ahash, this patch makes the mxs-dcp driver no longer use it. This driver didn't actually rely on it; it only writes to the result buffer in dcp_sha_req_to_buf(), using a bytewise copy. And this driver only supports unkeyed hash algorithms, so the key buffer need not be considered. Signed-off-by:
-
Eric Biggers authored
The crypto API's support for alignmasks for ahash algorithms is nearly useless, as its only effect is to cause the API to align the key and result buffers. The drivers that happen to be specifying an alignmask for ahash rarely actually need it. When they do, it's easily fixable, especially considering that these buffers cannot be used for DMA. In preparation for removing alignmask support from ahash, this patch makes the artpec6 driver no longer use it. This driver is unusual in that it DMAs the digest directly to the result buffer. This is broken because the crypto API provides the result buffer as an arbitrary virtual address, which might not be valid for DMA, even after the crypto API applies the alignmask. Maybe the alignmask (which this driver set only to 3) made this code work in a few more cases than it otherwise would have. But even if so, it doesn't make sense for this single driver that is broken anyway to block removal of the alignmask support. Signed-off-by:
-
Eric Biggers authored
The crypto API's support for alignmasks for ahash algorithms is nearly useless, as its only effect is to cause the API to align the key and result buffers. The drivers that happen to be specifying an alignmask for ahash rarely actually need it. When they do, it's easily fixable, especially considering that these buffers cannot be used for DMA. In preparation for removing alignmask support from ahash, this patch makes the atmel driver no longer use it. This driver didn't actually rely on it; it only writes to the result buffer in atmel_sha_copy_ready_hash(), simply using memcpy(). And this driver didn't set an alignmask for any keyed hash algorithms, so the key buffer need not be considered. Signed-off-by:
-
Eric Biggers authored
The crypto API's support for alignmasks for ahash algorithms is nearly useless, as its only effect is to cause the API to align the key and result buffers. The drivers that happen to be specifying an alignmask for ahash rarely actually need it. When they do, it's easily fixable, especially considering that these buffers cannot be used for DMA. In preparation for removing alignmask support from ahash, this patch makes the sun8i-ss driver no longer use it. This driver didn't actually rely on it; it only writes to the result buffer in sun8i_ss_hash_run(), simply using memcpy(). And sun8i_ss_hmac_setkey() does not assume any alignment for the key buffer. Signed-off-by:
Corentin Labbe <clabbe.montjoie@gmail.com> Signed-off-by:
-
Eric Biggers authored
The crypto API's support for alignmasks for ahash algorithms is nearly useless, as its only effect is to cause the API to align the key and result buffers. The drivers that happen to be specifying an alignmask for ahash rarely actually need it. When they do, it's easily fixable, especially considering that these buffers cannot be used for DMA. In preparation for removing alignmask support from ahash, this patch makes the sun8i-ce driver no longer use it. This driver didn't actually rely on it; it only writes to the result buffer in sun8i_ce_hash_run(), simply using memcpy(). And this driver only supports unkeyed hash algorithms, so the key buffer need not be considered. Signed-off-by:
-
Eric Biggers authored
The crypto API's support for alignmasks for ahash algorithms is nearly useless, as its only effect is to cause the API to align the key and result buffers. The drivers that happen to be specifying an alignmask for ahash rarely actually need it. When they do, it's easily fixable, especially considering that these buffers cannot be used for DMA. In preparation for removing alignmask support from ahash, this patch makes the sun4i-ss driver no longer use it. This driver didn't actually rely on it; it only writes to the result buffer in sun4i_hash(), already using the unaligned access helpers. And this driver only supports unkeyed hash algorithms, so the key buffer need not be considered. Signed-off-by:
-
Eric Biggers authored
crypto_shash_ctx_aligned() is no longer used, and it is useless now that shash algorithms don't support nonzero alignmasks, so remove it. Also remove crypto_tfm_ctx_aligned() which was only called by crypto_shash_ctx_aligned(). It's unlikely to be useful again, since it seems inappropriate to use cra_alignmask to represent alignment for the tfm context when it already means alignment for inputs/outputs. Signed-off-by:
-
Lukas Wunner authored
Per section 4.c. of the IETF Trust Legal Provisions, "Code Components" in IETF Documents are licensed on the terms of the BSD-3-Clause license: https://trustee.ietf.org/documents/trust-legal-provisions/tlp-5/ The term "Code Components" specifically includes ASN.1 modules: https://trustee.ietf.org/documents/trust-legal-provisions/code-components-list-3/ Add an SPDX identifier as well as a copyright notice pursuant to section 6.d. of the Trust Legal Provisions to all ASN.1 modules in the tree which are derived from IETF Documents. Section 4.d. of the Trust Legal Provisions requests that each Code Component identify the RFC from which it is taken, so link that RFC in every ASN.1 module. Signed-off-by:
Lukas Wunner <lukas@wunner.de> Signed-off-by:
-
Ashish Kalra authored
Brijesh is no longer with AMD. Signed-off-by:
Ashish Kalra <ashish.kalra@amd.com> Reviewed-by:
Michael Roth <michael.roth@amd.com> Acked-by:
Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by:
-
Giovanni Cabiddu authored
If a request has the flag CRYPTO_TFM_REQ_MAY_BACKLOG set, the function qat_alg_send_message_maybacklog(), enqueues it in a backlog list if either (1) there is already at least one request in the backlog list, or (2) the HW ring is nearly full or (3) the enqueue to the HW ring fails. If an interrupt occurs right before the lock in qat_alg_backlog_req() is taken and the backlog queue is being emptied, then there is no request in the HW queues that can trigger a subsequent interrupt that can clear the backlog queue. In addition subsequent requests are enqueued to the backlog list and not sent to the hardware. Fix it by holding the lock while taking the decision if the request needs to be included in the backlog queue or not. This synchronizes the flow with the interrupt handler that drains the backlog queue. For performance reasons, the logic has been changed to try to enqueue first without holding the lock. Fixes: 38682383 ("crypto: qat - add backlog mechanism") Reported-by:
Mikulas Patocka <mpatocka@redhat.com> Closes: https://lore.kernel.org/all/af9581e2-58f9-cc19-428f-6f18f1f83d54@redhat.com/T/Signed-off-by:
Giovanni Cabiddu <giovanni.cabiddu@intel.com> Reviewed-by:
-
