- 27 Oct, 2023 19 commits
-
-
Eric Biggers authored
Now that the shash algorithm type does not support nonzero alignmasks, crypto_shash_alignmask() always returns 0 and will be removed. In preparation for this, stop checking crypto_shash_alignmask() in testmgr. Signed-off-by:
Eric Biggers <ebiggers@google.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Eric Biggers authored
Now that the shash algorithm type does not support nonzero alignmasks, crypto_shash_alignmask() always returns 0 and will be removed. In preparation for this, stop checking crypto_shash_alignmask() in drbg. Signed-off-by:
-
Eric Biggers authored
Now that the shash algorithm type does not support nonzero alignmasks, crypto_shash_alignmask() always returns 0 and will be removed. In preparation for this, stop checking crypto_shash_alignmask() in net/ceph/messenger_v2.c. Signed-off-by:
-
Eric Biggers authored
Currently, the shash API checks the alignment of all message, key, and digest 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. In the case of the message buffer, cryptographic hash functions internally operate on fixed-size blocks, so implementations end up needing to deal with byte-aligned data anyway because the length(s) passed to ->update might not be divisible by the block size. Word-alignment of the message can theoretically be helpful for CRCs, like what was being done in crc32c-sparc64. But in practice it's better for the algorithms to use unaligned accesses or align the message themselves. A similar argument applies to the key and digest. In any case, no shash algorithms actually set a nonzero alignmask anymore. Therefore, remove support for it from shash. The benefit is that all the code to handle "misaligned" buffers in the shash API goes away, reducing the overhead of the shash API. Signed-off-by:
-
Eric Biggers authored
The xcbc template is setting its alignmask to that of its underlying 'cipher'. Yet, it doesn't care itself about how its inputs and outputs are aligned, which is ostensibly the point of the alignmask. Instead, xcbc actually just uses its alignmask itself to runtime-align certain fields in its tfm and desc contexts appropriately for its underlying cipher. That is almost entirely pointless too, though, since xcbc is already using the cipher API functions that handle alignment themselves, and few ciphers set a nonzero alignmask anyway. Also, even without runtime alignment, an alignment of at least 4 bytes can be guaranteed. Thus, at best this code is optimizing for the rare case of ciphers that set an alignmask >= 7, at the cost of hurting the common cases. Therefore, this patch removes the manual alignment code from xcbc and makes it stop setting an alignmask. Signed-off-by:
-
Eric Biggers authored
The vmac template is setting its alignmask to that of its underlying 'cipher'. This doesn't actually accomplish anything useful, though, so stop doing it. (vmac_update() does have an alignment bug, where it assumes u64 alignment when it shouldn't, but that bug exists both before and after this patch.) This is a prerequisite for removing support for nonzero alignmasks from shash. Signed-off-by:
-
Eric Biggers authored
The hmac template is setting its alignmask to that of its underlying unkeyed hash algorithm, and it is aligning the ipad and opad fields in its tfm context to that alignment. However, hmac does not actually need any sort of alignment itself, which makes this pointless except to keep the pads aligned to what the underlying algorithm prefers. But very few shash algorithms actually set an alignmask, and it is being removed from those remaining ones; also, after setkey, the pads are only passed to crypto_shash_import and crypto_shash_export which ignore the alignmask. Therefore, make the hmac template stop setting an alignmask and simply use natural alignment for ipad and opad. Note, this change also moves the pads from the beginning of the tfm context to the end, which makes much more sense; the variable-length fields should be at the end. Signed-off-by:
-
Eric Biggers authored
The cmac template is setting its alignmask to that of its underlying 'cipher'. Yet, it doesn't care itself about how its inputs and outputs are aligned, which is ostensibly the point of the alignmask. Instead, cmac actually just uses its alignmask itself to runtime-align certain fields in its tfm and desc contexts appropriately for its underlying cipher. That is almost entirely pointless too, though, since cmac is already using the cipher API functions that handle alignment themselves, and few ciphers set a nonzero alignmask anyway. Also, even without runtime alignment, an alignment of at least 4 bytes can be guaranteed. Thus, at best this code is optimizing for the rare case of ciphers that set an alignmask >= 7, at the cost of hurting the common cases. Therefore, this patch removes the manual alignment code from cmac and makes it stop setting an alignmask. Signed-off-by:
-
Eric Biggers authored
The cbcmac template is aligning a field in its desc context to the alignmask of its underlying 'cipher', at runtime. This is almost entirely pointless, since cbcmac is already using the cipher API functions that handle alignment themselves, and few ciphers set a nonzero alignmask anyway. Also, even without runtime alignment, an alignment of at least 4 bytes can be guaranteed. Thus, at best this code is optimizing for the rare case of ciphers that set an alignmask >= 7, at the cost of hurting the common cases. Therefore, remove the manual alignment code from cbcmac. Signed-off-by:
-
Eric Biggers authored
This unnecessary explicit setting of cra_alignmask to 0 shows up when grepping for shash algorithms that set an alignmask. Remove it. No change in behavior. Signed-off-by:
-
Eric Biggers authored
This unnecessary explicit setting of cra_alignmask to 0 shows up when grepping for shash algorithms that set an alignmask. Remove it. No change in behavior. Signed-off-by:
-
Eric Biggers authored
The zynqmp-sha3-384 algorithm sets a nonzero alignmask, but it doesn't appear to actually need it. Therefore, stop setting it. This will allow this algorithm to keep being registered after alignmask support is removed from shash. Signed-off-by:
-
Eric Biggers authored
The stm32 crc32 algorithms set a nonzero alignmask, but they don't seem to actually need it. Their ->update function already has code that handles aligning the data to the same alignment that the alignmask specifies, their ->setkey function already uses get_unaligned_le32(), and their ->final function already uses put_unaligned_le32(). Therefore, stop setting the alignmask. This will allow these algorithms to keep being registered after alignmask support is removed from shash. Signed-off-by:
-
Eric Biggers authored
As far as I can tell, "crc32c-sparc64" is the only "shash" algorithm in the kernel that sets a nonzero alignmask and actually relies on it to get the crypto API to align the inputs and outputs. This capability is not really useful, though. To unblock removing the support for alignmask from shash_alg, this patch updates crc32c-sparc64 to no longer use the alignmask. This means doing 8-byte alignment of the data when doing an update, using get_unaligned_le32() when setting a non-default initial CRC, and using put_unaligned_le32() to output the final CRC. Partially tested with: export ARCH=sparc64 CROSS_COMPILE=sparc64-linux-gnu- make sparc64_defconfig echo CONFIG_CRYPTO_CRC32C_SPARC64=y >> .config echo '# CONFIG_CRYPTO_MANAGER_DISABLE_TESTS is not set' >> .config echo CONFIG_DEBUG_KERNEL=y >> .config echo CONFIG_CRYPTO_MANAGER_EXTRA_TESTS=y >> .config make olddefconfig make -j$(getconf _NPROCESSORS_ONLN) qemu-system-sparc64 -kernel arch/sparc/boot/image -nographic However, qemu doesn't actually support the sparc CRC32C instructions, so for the test I temporarily replaced crc32c_sparc64() with __crc32c_le() and made sparc64_has_crc32c_opcode() always return true. So essentially I tested the glue code, not the actual SPARC part which is unchanged. Signed-off-by: -
Eric Biggers authored
Most shash algorithms don't have custom ->import and ->export functions, resulting in the memcpy() based default being used. Yet, crypto_shash_import() and crypto_shash_export() still make an indirect call, which is expensive. Therefore, change how the default import and export are called to make it so that crypto_shash_import() and crypto_shash_export() don't do an indirect call in this case. Signed-off-by:
-
Om Prakash Singh authored
Document SA8775P and SC7280 compatible for the True Random Number Generator. Signed-off-by:
Om Prakash Singh <quic_omprsing@quicinc.com> Reviewed-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by:
Bjorn Andersson <andersson@kernel.org> Signed-off-by:
-
Herbert Xu authored
Add a module alias for pkcs1pas so that it can be auto-loaded by modprobe. Signed-off-by: -
Herbert Xu authored
The modular build fails because the self-test code depends on pkcs7 which in turn depends on x509 which contains the self-test. Split the self-test out into its own module to break the cycle. Fixes: 3cde3174 ("certs: Add FIPS selftests") Signed-off-by:
Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by:
-
WangJinchao authored
In a high-load arm64 environment, the pcrypt_aead01 test in LTP can lead to system UAF (Use-After-Free) issues. Due to the lengthy analysis of the pcrypt_aead01 function call, I'll describe the problem scenario using a simplified model: Suppose there's a user of padata named `user_function` that adheres to the padata requirement of calling `padata_free_shell` after `serial()` has been invoked, as demonstrated in the following code: ```c struct request { struct padata_priv padata; struct completion *done; }; void parallel(struct padata_priv *padata) { do_something(); } void serial(struct padata_priv *padata) { struct request *request = container_of(padata, struct request, padata); complete(request->done); } void user_function() { DECLARE_COMPLETION(done) padata->parallel = parallel; padata->serial = serial; padata_do_parallel(); wait_for_completion(&done); padata_free_shell(); } ``` In the corresponding padata.c file, there's the following code: ```c static void padata_serial_worker(struct work_struct *serial_work) { ... cnt = 0; while (!list_empty(&local_list)) { ... padata->serial(padata); cnt++; } local_bh_enable(); if (refcount_sub_and_test(cnt, &pd->refcnt)) padata_free_pd(pd); } ``` Because of the high system load and the accumulation of unexecuted softirq at this moment, `local_bh_enable()` in padata takes longer to execute than usual. Subsequently, when accessing `pd->refcnt`, `pd` has already been released by `padata_free_shell()`, resulting in a UAF issue with `pd->refcnt`. The fix is straightforward: add `refcount_dec_and_test` before calling `padata_free_pd` in `padata_free_shell`. Fixes: 07928d9b ("padata: Remove broken queue flushing") Signed-off-by:WangJinchao <wangjinchao@xfusion.com> Acked-by:
Daniel Jordan <daniel.m.jordan@oracle.com> Acked-by:
-
- 20 Oct, 2023 21 commits
-
-
André Apitzsch authored
This should fix the undefined reference: > /usr/bin/aarch64-alpine-linux-musl-ld: Unexpected GOT/PLT entries detected! > /usr/bin/aarch64-alpine-linux-musl-ld: Unexpected run-time procedure linkages detected! > /usr/bin/aarch64-alpine-linux-musl-ld: drivers/crypto/qcom-rng.o: in function `qcom_rng_probe': > qcom-rng.c:(.text+0x130): undefined reference to `devm_hwrng_register' Fixes: f29cd5bb ("crypto: qcom-rng - Add hw_random interface support") Signed-off-by:
André Apitzsch <git@apitzsch.eu> Reviewed-by:
Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by:
-
Eric Biggers authored
When an algorithm of the new "lskcipher" type is exposed through the "skcipher" API, calls to crypto_skcipher_setkey() don't pass on the CRYPTO_TFM_REQ_FORBID_WEAK_KEYS flag to the lskcipher. This causes self-test failures for ecb(des), as weak keys are not rejected anymore. Fix this. Fixes: 31865c4c ("crypto: skcipher - Add lskcipher") Signed-off-by:
-
Longfang Liu authored
During hisilicon accelerator live migration operation. In order to prevent the problem of EQ/AEQ interrupt loss. Migration driver will trigger an EQ/AEQ doorbell at the end of the migration. This operation may cause double interruption of EQ/AEQ events. To ensure that the EQ/AEQ interrupt processing function is normal. The interrupt handling functionality of EQ/AEQ needs to be updated. Used to handle repeated interrupts event. Fixes: b0eed085 ("hisi_acc_vfio_pci: Add support for VFIO live migration") Signed-off-by:
Longfang Liu <liulongfang@huawei.com> Signed-off-by:
-
Herbert Xu authored
The heuristics used by gcc triggers false positive truncation warnings in hifn_alg_alloc. The warning triggered by the strings here are clearly false positives (see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95755). Add checks on snprintf calls to silence these warnings, including the one for cra_driver_name even though it does not currently trigger a gcc warning. Signed-off-by:
-
Herbert Xu authored
Set the error value to -EINVAL instead of zero when the underlying name (within "ecb()") fails basic sanity checks. Fixes: 8aee5d4e ("crypto: lskcipher - Add compatibility wrapper around ECB") Reported-by:
kernel test robot <lkp@intel.com> Reported-by:
Dan Carpenter <dan.carpenter@linaro.org> Closes: https://lore.kernel.org/r/202310111323.ZjK7bzjw-lkp@intel.com/Signed-off-by:
-
Dimitri John Ledkov authored
NIST FIPS 186-5 states that it is recommended that the security strength associated with the bit length of n and the security strength of the hash function be the same, or higher upon agreement. Given NIST P384 curve is used, force using either SHA384 or SHA512. Signed-off-by:
Dimitri John Ledkov <dimitri.ledkov@canonical.com> Signed-off-by:
-
Dimitri John Ledkov authored
sha224 does not provide enough security against collision attacks relative to the default keys used for signing (RSA 4k & P-384). Also sha224 never became popular, as sha256 got widely adopter ahead of sha224 being introduced. Signed-off-by:
-
Dimitri John Ledkov authored
It is possible to stand up own certificates and sign PE-COFF binaries using SHA-224. However it never became popular or needed since it has similar costs as SHA-256. Windows Authenticode infrastructure never had support for SHA-224, and all secureboot keys used fro linux vmlinuz have always been using at least SHA-256. Given the point of mscode_parser is to support interoperatiblity with typical de-facto hashes, remove support for SHA-224 to avoid posibility of creating interoperatibility issues with rhboot/shim, grub, and non-linux systems trying to sign or verify vmlinux. SHA-224 itself is not removed from the kernel, as it is truncated SHA-256. If requested I can write patches to remove SHA-224 support across all of the drivers. Signed-off-by:
Ard Biesheuvel <ardb@kernel.org> Signed-off-by:
-
Dimitri John Ledkov authored
Removes support for sha1 signed kernel modules, importing sha1 signed x.509 certificates. rsa-pkcs1pad keeps sha1 padding support, which seems to be used by virtio driver. sha1 remains available as there are many drivers and subsystems using it. Note only hmac(sha1) with secret keys remains cryptographically secure. In the kernel there are filesystems, IMA, tpm/pcr that appear to be using sha1. Maybe they can all start to be slowly upgraded to something else i.e. blake3, ParallelHash, SHAKE256 as needed. Signed-off-by:
-
John Allen authored
PSP firmware may report additional error information in the SEV command buffer registers in situations where an error occurs as the result of an SEV command. In this case, check if the command buffer registers have been modified and if so, dump the contents. Signed-off-by:
John Allen <john.allen@amd.com> Reviewed-by:
Mario Limonciello <mario.limonciello@amd.com> Reviewed-by:
Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by:
-
Eric Biggers authored
In the Linux kernel, a function whose name has two leading underscores is conventionally called by the same-named function without leading underscores -- not the other way around. __sha512_block_data_order() got this backwards. Fix this, albeit without changing the name in the perlasm since that is OpenSSL code. No change in behavior. Signed-off-by:
-
Eric Biggers authored
In the Linux kernel, a function whose name has two leading underscores is conventionally called by the same-named function without leading underscores -- not the other way around. __sha256_block_data_order() and __sha256_block_neon() got this backwards. Fix this, albeit without changing the names in the perlasm since that is OpenSSL code. No change in behavior. Signed-off-by:
-
Eric Biggers authored
In the Linux kernel, a function whose name has two leading underscores is conventionally called by the same-named function without leading underscores -- not the other way around. __sha512_ce_transform() and __sha512_block_data_order() got this backwards. Fix this, albeit without changing "sha512_block_data_order" in the perlasm since that is OpenSSL code. No change in behavior. Signed-off-by:
-
Eric Biggers authored
In the Linux kernel, a function whose name has two leading underscores is conventionally called by the same-named function without leading underscores -- not the other way around. __sha2_ce_transform() and __sha256_block_data_order() got this backwards. Fix this, albeit without changing "sha256_block_data_order" in the perlasm since that is OpenSSL code. No change in behavior. Signed-off-by:
-
Eric Biggers authored
In the Linux kernel, a function whose name has two leading underscores is conventionally called by the same-named function without leading underscores -- not the other way around. __sha1_ce_transform() got this backwards. Fix this. No change in behavior. Signed-off-by:
-
Eric Biggers authored
Implement the ->digest method to improve performance on single-page messages by reducing the number of indirect calls. Signed-off-by:
-
Eric Biggers authored
Implement the ->digest method to improve performance on single-page messages by reducing the number of indirect calls. Signed-off-by:
-
Eric Biggers authored
Implement the ->digest method to improve performance on single-page messages by reducing the number of indirect calls. Signed-off-by:
-
Eric Biggers authored
When the source scatterlist is a single page, optimize the first hash step of adiantum to use crypto_shash_digest() instead of init/update/final, and use the same local kmap for both hashing the bulk part and loading the narrow part of the source data. Likewise, when the destination scatterlist is a single page, optimize the second hash step of adiantum to use crypto_shash_digest() instead of init/update/final, and use the same local kmap for both hashing the bulk part and storing the narrow part of the destination data. In some cases these optimizations improve performance significantly. Note: ideally, for optimal performance each architecture should implement the full "adiantum(xchacha12,aes)" algorithm and fully optimize the contiguous buffer case to use no indirect calls. That's not something I've gotten around to doing, though. This commit just makes a relatively small change that provides some benefit with the existing template-based approach. Signed-off-by:
-
Svyatoslav Pankratov authored
There is no need to free the reset_data structure if the recovery is unsuccessful and the reset is synchronous. The function adf_dev_aer_schedule_reset() handles the cleanup properly. Only asynchronous resets require such structure to be freed inside the reset worker. Fixes: d8cba25d ("crypto: qat - Intel(R) QAT driver framework") Signed-off-by:
Svyatoslav Pankratov <svyatoslav.pankratov@intel.com> Signed-off-by:
Giovanni Cabiddu <giovanni.cabiddu@intel.com> Signed-off-by:
-
Eric Biggers authored
Implement a ->digest function for sha256-ssse3, sha256-avx, sha256-avx2, and sha256-ni. This improves the performance of crypto_shash_digest() with these algorithms by reducing the number of indirect calls that are made. For now, don't bother with this for sha224, since sha224 is rarely used. Signed-off-by:
-
