- 20 Oct, 2023 26 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:
Herbert Xu <herbert@gondor.apana.org.au>
-
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:
Eric Biggers <ebiggers@google.com> 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:
-
Eric Biggers authored
Implement a ->digest function for sha256-ce. This improves the performance of crypto_shash_digest() with this algorithm by reducing the number of indirect calls that are made. This only adds ~112 bytes of code, mostly for the inlined init, as the finup function is tail-called. For now, don't bother with this for sha224, since sha224 is rarely used. Signed-off-by:
-
Eric Biggers authored
Fold shash_digest_unaligned() into its only remaining caller. Also, avoid a redundant check of CRYPTO_TFM_NEED_KEY by replacing the call to crypto_shash_init() with shash->init(desc). Finally, replace shash_update_unaligned() + shash_final_unaligned() with shash_finup_unaligned() which does exactly that. Signed-off-by:
-
Eric Biggers authored
For an shash algorithm that doesn't implement ->digest, currently crypto_shash_digest() with aligned input makes 5 indirect calls: 1 to shash_digest_unaligned(), 1 to ->init, 2 to ->update ('alignmask + 1' bytes, then the rest), then 1 to ->final. This is true even if the algorithm implements ->finup. This is caused by an unnecessary fallback to code meant to handle unaligned inputs. In fact, crypto_shash_digest() already does the needed alignment check earlier. Therefore, optimize the number of indirect calls for aligned inputs to 3 when the algorithm implements ->finup. It remains at 5 when the algorithm implements neither ->finup nor ->digest. Similarly, for an shash algorithm that doesn't implement ->finup, currently crypto_shash_finup() with aligned input makes 4 indirect calls: 1 to shash_finup_unaligned(), 2 to ->update, and 1 to ->final. Optimize this to 3 calls. Signed-off-by: -
Eric Biggers authored
Since commit adad556e ("crypto: api - Fix built-in testing dependency failures"), the following warning appears when booting an x86_64 kernel that is configured with CONFIG_CRYPTO_MANAGER_EXTRA_TESTS=y and CONFIG_CRYPTO_AES_NI_INTEL=y, even when CONFIG_CRYPTO_XTS=y and CONFIG_CRYPTO_AES=y: alg: skcipher: skipping comparison tests for xts-aes-aesni because xts(ecb(aes-generic)) is unavailable This is caused by an issue in the xts template where it allocates an "aes" single-block cipher without declaring a dependency on it via the crypto_spawn mechanism. This issue was exposed by the above commit because it reversed the order that the algorithms are tested in. Specifically, when "xts(ecb(aes-generic))" is instantiated and tested during the comparison tests for "xts-aes-aesni", the "xts" template allocates an "aes" crypto_cipher for encrypting tweaks. This resolves to "aes-aesni". (Getting "aes-aesni" instead of "aes-generic" here is a bit weird, but it's apparently intended.) Due to the above-mentioned commit, the testing of "aes-aesni", and the finalization of its registration, now happens at this point instead of before. At the end of that, crypto_remove_spawns() unregisters all algorithm instances that depend on a lower-priority "aes" implementation such as "aes-generic" but that do not depend on "aes-aesni". However, because "xts" does not use the crypto_spawn mechanism for its "aes", its dependency on "aes-aesni" is not recognized by crypto_remove_spawns(). Thus, crypto_remove_spawns() unexpectedly unregisters "xts(ecb(aes-generic))". Fix this issue by making the "xts" template use the crypto_spawn mechanism for its "aes" dependency, like what other templates do. Note, this fix could be applied as far back as commit f1c131b4 ("crypto: xts - Convert to skcipher"). However, the issue only got exposed by the much more recent changes to how the crypto API runs the self-tests, so there should be no need to backport this to very old kernels. Also, an alternative fix would be to flip the list iteration order in crypto_start_tests() to restore the original testing order. I'm thinking we should do that too, since the original order seems more natural, but it shouldn't be relied on for correctness. Fixes: adad556e ("crypto: api - Fix built-in testing dependency failures") Signed-off-by:
-
zhenwei pi authored
MST pointed out: config change callback is also handled incorrectly in this driver, it takes a mutex from interrupt context. Handle config changed by work queue instead. Cc: Gonglei (Arei) <arei.gonglei@huawei.com> Cc: Halil Pasic <pasic@linux.ibm.com> Cc: Michael S. Tsirkin <mst@redhat.com> Signed-off-by:
zhenwei pi <pizhenwei@bytedance.com> Signed-off-by:
-
- 14 Oct, 2023 1 commit
-
-
Weili Qian authored
If the temporarily applied memory is used to set or get the xqc information, the driver releases the memory immediately after the hardware mailbox operation time exceeds the driver waiting time. However, the hardware does not cancel the operation, so the hardware may write data to released memory. Therefore, when the driver is bound to a device, the driver reserves memory for the xqc configuration. The subsequent xqc configuration uses the reserved memory to prevent hardware from accessing the released memory. Signed-off-by:
Weili Qian <qianweili@huawei.com> Signed-off-by:
-
- 13 Oct, 2023 13 commits
-
-
Stephan Müller authored
In case a health test error occurs during runtime, the power-up health tests are rerun to verify that the noise source is still good and that the reported health test error was an outlier. For performing this power-up health test, the already existing entropy collector instance is used instead of allocating a new one. This change has the following implications: * The noise that is collected as part of the newly run health tests is inserted into the entropy collector and thus stirs the existing data present in there further. Thus, the entropy collected during the health test is not wasted. This is also allowed by SP800-90B. * The power-on health test is not affected by the state of the entropy collector, because it resets the APT / RCT state. The remainder of the state is unrelated to the health test as it is only applied to newly obtained time stamps. This change also fixes a bug report about an allocation while in an atomic lock (the lock is taken in jent_kcapi_random, jent_read_entropy is called and this can call jent_entropy_init). Fixes: 04597c8d ("jitter - add RCT/APT support for different OSRs") Reported-by:
Stephan Mueller <smueller@chronox.de> Signed-off-by:
-
Rob Herring authored
Use preferred device_get_match_data() instead of of_match_device() to get the driver match data. With this, adjust the includes to explicitly include the correct headers. Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Rob Herring authored
Use preferred device_get_match_data() instead of of_match_device() to get the driver match data. With this, adjust the includes to explicitly include the correct headers. Signed-off-by:
Andrew Jeffery <andrew@codeconstruct.com.au> Reviewed-by:
Neal Liu <neal_liu@aspeedtech.com> Signed-off-by:
-
Lucas Segarra Fernandez authored
The Compress and Verify (CnV) feature check and ensures data integrity in the compression operation. The implementation of CnV keeps a record of the CnV errors that have occurred since the driver was loaded. Expose CnV error stats by providing the "cnv_errors" file under debugfs. This includes the number of errors detected up to now and the type of the last error. The error count is provided on a per Acceleration Engine basis and it is reset every time the driver is loaded. Signed-off-by:
Lucas Segarra Fernandez <lucas.segarra.fernandez@intel.com> Reviewed-by:
-
Lucas Segarra Fernandez authored
QAT devices implement a mechanism that allows them to go autonomously to a low power state depending on the load. Expose power management info by providing the "pm_status" file under debugfs. This includes PM state, PM event log, PM event counters, PM HW CSRs, per-resource type constrain counters and per-domain power gating status specific to the QAT device. This information is retrieved from (1) the FW by means of ICP_QAT_FW_PM_INFO command, (2) CSRs and (3) counters collected by the device driver. In addition, add logic to keep track and report power management event interrupts and acks/nacks sent to FW to allow/prevent state transitions. Signed-off-by:
-
Lucas Segarra Fernandez authored
Include kernel.h for GENMASK(), kstrtobool() and types. Add forward declaration for struct adf_accel_dev. Remove unneeded include. This change doesn't introduce any function change. Signed-off-by:
-
Om Prakash Singh authored
Add hw_random interface support in qcom-rng driver as new IP block in Qualcomm SoC has inbuilt NIST SP800 90B compliant entropic source to generate true random number. Keeping current rng_alg interface as well for random number generation using Kernel Crypto API. Signed-off-by:
Om Prakash Singh <quic_omprsing@quicinc.com> Reviewed-by:
Bjorn Andersson <quic_bjorande@quicinc.com> Signed-off-by:
-
Neil Armstrong authored
Document SM8550 compatible for the True Random Number Generator. Reviewed-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by:
-
Neil Armstrong authored
It has been reported at [1] the RNG HW on SM8450 is in fact a True Random Number Generator and no more Pseudo, document this by adding a new qcom,trng and the corresponding SoC specific sm8450 compatible. [1] https://lore.kernel.org/all/20230818161720.3644424-1-quic_omprsing@quicinc.com/Suggested-by:
Konrad Dybcio <konrad.dybcio@linaro.org> Reviewed-by:
-
Herbert Xu authored
As skcipher spawn users can no longer assume the spawn is of type struct skcipher_alg, these helpers are no longer used. Remove them. Signed-off-by: -
Herbert Xu authored
As skcipher spawns may be of the type lskcipher, only the common fields may be accessed. This was already the case but use the correct helpers to make this more obvious. Signed-off-by: -
Herbert Xu authored
As skcipher spawns may be of the type lskcipher, only the common fields may be accessed. This was already the case but use the correct helpers to make this more obvious. Signed-off-by: -
Herbert Xu authored
As skcipher spawns may be of the type lskcipher, only the common fields may be accessed. This was already the case but use the correct helpers to make this more obvious. Signed-off-by:
-
