- 20 Apr, 2023 12 commits
-
-
Ard Biesheuvel authored
Avoid cluttering up the kallsyms symbol table with entries that should not end up in things like backtraces, as they have undescriptive and generated identifiers. Signed-off-by:
Ard Biesheuvel <ardb@kernel.org> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Ard Biesheuvel authored
Avoid cluttering up the kallsyms symbol table with entries that should not end up in things like backtraces, as they have undescriptive and generated identifiers. Signed-off-by:
Ard Biesheuvel <ardb@kernel.org> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Ard Biesheuvel authored
Prefer RIP-relative addressing where possible, which removes the need for boot time relocation fixups. Signed-off-by:
Ard Biesheuvel <ardb@kernel.org> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Ard Biesheuvel authored
Prefer RIP-relative addressing where possible, which removes the need for boot time relocation fixups. Signed-off-by:
Ard Biesheuvel <ardb@kernel.org> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Ard Biesheuvel authored
Prefer RIP-relative addressing where possible, which removes the need for boot time relocation fixups. Co-developed-by:
Thomas Garnier <thgarnie@chromium.org> Signed-off-by:
Thomas Garnier <thgarnie@chromium.org> Signed-off-by:
Ard Biesheuvel <ardb@kernel.org> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Ard Biesheuvel authored
Prefer RIP-relative addressing where possible, which removes the need for boot time relocation fixups. Signed-off-by:
Ard Biesheuvel <ardb@kernel.org> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Ard Biesheuvel authored
Prefer RIP-relative addressing where possible, which removes the need for boot time relocation fixups. Co-developed-by:
Thomas Garnier <thgarnie@chromium.org> Signed-off-by:
Thomas Garnier <thgarnie@chromium.org> Signed-off-by:
Ard Biesheuvel <ardb@kernel.org> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Ard Biesheuvel authored
Prefer RIP-relative addressing where possible, which removes the need for boot time relocation fixups. Co-developed-by:
Thomas Garnier <thgarnie@chromium.org> Signed-off-by:
Thomas Garnier <thgarnie@chromium.org> Signed-off-by:
Ard Biesheuvel <ardb@kernel.org> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Ard Biesheuvel authored
Prefer RIP-relative addressing where possible, which removes the need for boot time relocation fixups. Co-developed-by:
Thomas Garnier <thgarnie@chromium.org> Signed-off-by:
Thomas Garnier <thgarnie@chromium.org> Signed-off-by:
Ard Biesheuvel <ardb@kernel.org> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Ard Biesheuvel authored
Prefer RIP-relative addressing where possible, which removes the need for boot time relocation fixups. Signed-off-by:
Ard Biesheuvel <ardb@kernel.org> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Ard Biesheuvel authored
Prefer RIP-relative addressing where possible, which removes the need for boot time relocation fixups. In the GCM case, we can get rid of the oversized permutation array entirely while at it. Signed-off-by:
Ard Biesheuvel <ardb@kernel.org> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Ard Biesheuvel authored
Prefer RIP-relative addressing where possible, which removes the need for boot time relocation fixups. Signed-off-by:
Ard Biesheuvel <ardb@kernel.org> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
- 14 Apr, 2023 9 commits
-
-
Arnd Bergmann authored
The crypt_ctl structure must be exactly 64 bytes long to work correctly, and it has to be a power-of-two size to allow turning the 64-bit division in crypt_phys2virt() into a shift operation, avoiding the link failure: ERROR: modpost: "__aeabi_uldivmod" [drivers/crypto/intel/ixp4xx/ixp4xx_crypto.ko] undefined! The failure now shows up because the driver is available for compile testing after the move, and a previous fix turned the more descriptive BUILD_BUG_ON() into a link error. Change the variably-sized dma_addr_t into the expected 'u32' type that is needed for the hardware, and reinstate the size check for all 32-bit architectures to simplify debugging if it hits again. Fixes: 1bc7fdbf ("crypto: ixp4xx - Move driver to drivers/crypto/intel/ixp4xx") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Horia GeantA authored
caam driver needs to be aware of OP-TEE f/w presence, since some things are done differently: 1. there is no access to controller's register page (note however that some registers are aliased in job rings' register pages) 2 Due to this, MCFGR[PS] cannot be read and driver assumes MCFGR[PS] = b'0 - engine using 32-bit address pointers. This is in sync with the fact that: -all i.MX SoCs currently use MCFGR[PS] = b'0 -only i.MX OP-TEE use cases don't allow access to controller register page Signed-off-by:
Horia GeantA <horia.geanta@nxp.com> Signed-off-by:
Meenakshi Aggarwal <meenakshi.aggarwal@nxp.com> Reviewed-by:
Gaurav Jain <gaurav.jain@nxp.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Horia GeantA authored
Use job ring register map, in place of controller register map to access page 0 registers, as access to the controller register map is not permitted. Signed-off-by:
Horia GeantA <horia.geanta@nxp.com> Signed-off-by:
Gaurav Jain <gaurav.jain@nxp.com> Signed-off-by:
Meenakshi Aggarwal <meenakshi.aggarwal@nxp.com> Reviewed-by:
Varun Sethi <v.sethi@nxp.com> Reviewed-by:
Gaurav Jain <gaurav.jain@nxp.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Mario Limonciello authored
Unlike other command registers used by the PSP, only the lower 8 bytes are used for communication for both command and status of the command. Suggested-by:
Mark Hasemeyer <markhas@chromium.org> Signed-off-by:
Mario Limonciello <mario.limonciello@amd.com> Reviewed-by:
Mark Hasemeyer <markhas@chromium.org> Tested-by:
Mark Hasemeyer <markhas@chromium.org> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Mario Limonciello authored
If the doorbell failed to ring we return -EIO, but the caller can't determine why it failed. Pass the reason for the failure in an argument for caller to investigate. Suggested-by:
Mark Hasemeyer <markhas@chromium.org> Signed-off-by:
Mario Limonciello <mario.limonciello@amd.com> Reviewed-by:
Mark Hasemeyer <markhas@chromium.org> Tested-by:
Mark Hasemeyer <markhas@chromium.org> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Mario Limonciello authored
This is helpful not just for debugging problems, but also for investigating captured logs later on. Suggested-by:
Grzegorz Bernacki <gjb@semihalf.com> Signed-off-by:
Mario Limonciello <mario.limonciello@amd.com> Tested-by:
Mark Hasemeyer <markhas@chromium.org> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Mario Limonciello authored
The doorbell register set used for I2C arbitration is dedicated for this purpose and there is no need to utilize other safety checks the platform access register set uses. Suggested-by:
Mark Hasemeyer <markhas@chromium.org> Signed-off-by:
Mario Limonciello <mario.limonciello@amd.com> Reviewed-by:
Mark Hasemeyer <markhas@chromium.org> Tested-by:
Mark Hasemeyer <markhas@chromium.org> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Mario Limonciello authored
A number of platforms are emitting the error: ```ccp: unable to access the device: you might be running a broken BIOS.``` This is expected behavior as CCP is no longer accessible from the PSP's PCIe BAR so stop trying to probe CCP for 0x1649. Cc: stable@vger.kernel.org Signed-off-by:
Mario Limonciello <mario.limonciello@amd.com> Acked-by:
Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Herbert Xu authored
A number of low-level functions were exposed in crypto.h. Move them into algapi.h (and internal.h). Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
- 11 Apr, 2023 1 commit
-
-
Herbert Xu authored
The BUILD_BUG_ON preventing compilation on foreign architectures should be disabled when we're doing compile testing. Fixes: 1bc7fdbf ("crypto: ixp4xx - Move driver to...") Reported-by:
kernel test robot <lkp@intel.com> Link: https://lore.kernel.org/oe-kbuild-all/202304061846.G6cpPXiQ-lkp@intel.com/Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
- 06 Apr, 2023 13 commits
-
-
David Yang authored
HiSTB TRNG are found on some HiSilicon STB SoCs. Signed-off-by:
David Yang <mmyangfl@gmail.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Ryan Wanner authored
Change blocksize to match the cfb(aes) generic implementation. Signed-off-by:
Ryan Wanner <Ryan.Wanner@microchip.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Ryan Wanner authored
Avoiding detecting finely in-place operations with different scatter lists. Copying the source data for decryption into rctx->lastc regardless if the operation is in-place or not. This allows in-place operations with different scatter lists. This approach takes less resources than parsing both scatter lists to check if they are equal. Signed-off-by:
Ryan Wanner <Ryan.Wanner@microchip.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Ryan Wanner authored
Avoiding detecting finely in-place operations with different scatter lists. Copying the source data for decryption into rctx->lastc regardless if the operation is in-place or not. This allows in-place operations with different scatter lists without affecting other operations. This approach takes less resources than parsing both scatter lists to check if they are equal. Signed-off-by:
Ryan Wanner <Ryan.Wanner@microchip.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Ryan Wanner authored
Add softare padding to hmac-sha digest for zero length messages. Using the atmel_sha_fill_padding() to fill the buffer with a padded empty message with a length of the block size. Create a temporary scatter list from the padded buffer to pass into the data processing functions. Signed-off-by:
Ryan Wanner <Ryan.Wanner@microchip.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Tom Zanussi authored
With the growing number of Intel crypto drivers, it makes sense to group them all into a single drivers/crypto/intel/ directory. Signed-off-by:
Tom Zanussi <tom.zanussi@linux.intel.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Tom Zanussi authored
With the growing number of Intel crypto drivers, it makes sense to group them all into a single drivers/crypto/intel/ directory. Create a separate drivers/crypto/intel/ixp4xx directory and move drivers/crypto/ixp4xx_crypto.c to it, along with a new Kconfig and Makefile to contain the config and make bits. Also add a COMPILE_TEST dependency to CRYPTO_DEV_IXP4XX so it can be more easily compile-tested. Signed-off-by:
Tom Zanussi <tom.zanussi@linux.intel.com> Acked-by:
Corentin LABBE <clabbe@baylibre.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Tom Zanussi authored
With the growing number of Intel crypto drivers, it makes sense to group them all into a single drivers/crypto/intel/ directory. Signed-off-by:
Tom Zanussi <tom.zanussi@linux.intel.com> Acked-by:
Daniele Alessandrelli <daniele.alessandrelli@intel.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Jeremi Piotrowski authored
The PSP IRQ is edge-triggered (MSI or MSI-X) in all cases supported by the psp module so clear the interrupt status register early in the handler to prevent missed interrupts. sev_irq_handler() calls wake_up() on a wait queue, which can result in a new command being submitted from a different CPU. This then races with the clearing of isr and can result in missed interrupts. A missed interrupt results in a command waiting until it times out, which results in the psp being declared dead. This is unlikely on bare metal, but has been observed when running virtualized. In the cases where this is observed, sev->cmdresp_reg has PSP_CMDRESP_RESP set which indicates that the command was processed correctly but no interrupt was asserted. The full sequence of events looks like this: CPU 1: submits SEV cmd #1 CPU 1: calls wait_event_timeout() CPU 0: enters psp_irq_handler() CPU 0: calls sev_handler()->wake_up() CPU 1: wakes up; finishes processing cmd #1 CPU 1: submits SEV cmd #2 CPU 1: calls wait_event_timeout() PSP: finishes processing cmd #2; interrupt status is still set; no interrupt CPU 0: clears intsts CPU 0: exits psp_irq_handler() CPU 1: wait_event_timeout() times out; psp_dead=true Fixes: 200664d5 ("crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support") Cc: stable@vger.kernel.org Signed-off-by:
Jeremi Piotrowski <jpiotrowski@linux.microsoft.com> Acked-by:
Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Herbert Xu authored
Remove the HASH_MAX_STATESIZE limit now that it is unused. Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Herbert Xu authored
Allocating the hash state on the stack limits its size. Change this to use kmalloc so the limit can be removed for new drivers. Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Herbert Xu authored
When jent initialisation fails for any reason other than ENOENT, the entire drbg fails to initialise, even when we're not in FIPS mode. This is wrong because we can still use the kernel RNG when we're not in FIPS mode. Change it so that it only fails when we are in FIPS mode. Fixes: 57225e67 ("crypto: drbg - Use callback API for random readiness") Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Reviewed-by:
Stephan Mueller <smueller@chronox.de> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Stephan Müller authored
According to SP800-90B, two health failures are allowed: the intermittend and the permanent failure. So far, only the intermittent failure was implemented. The permanent failure was achieved by resetting the entire entropy source including its health test state and waiting for two or more back-to-back health errors. This approach is appropriate for RCT, but not for APT as APT has a non-linear cutoff value. Thus, this patch implements 2 cutoff values for both RCT/APT. This implies that the health state is left untouched when an intermittent failure occurs. The noise source is reset and a new APT powerup-self test is performed. Yet, whith the unchanged health test state, the counting of failures continues until a permanent failure is reached. Any non-failing raw entropy value causes the health tests to reset. The intermittent error has an unchanged significance level of 2^-30. The permanent error has a significance level of 2^-60. Considering that this level also indicates a false-positive rate (see SP800-90B section 4.2) a false-positive must only be incurred with a low probability when considering a fleet of Linux kernels as a whole. Hitting the permanent error may cause a panic(), the following calculation applies: Assuming that a fleet of 10^9 Linux kernels run concurrently with this patch in FIPS mode and on each kernel 2 health tests are performed every minute for one year, the chances of a false positive is about 1:1000 based on the binomial distribution. In addition, any power-up health test errors triggered with jent_entropy_init are treated as permanent errors. A permanent failure causes the entire entropy source to permanently return an error. This implies that a caller can only remedy the situation by re-allocating a new instance of the Jitter RNG. In a subsequent patch, a transparent re-allocation will be provided which also changes the implied heuristic entropy assessment. In addition, when the kernel is booted with fips=1, the Jitter RNG is defined to be part of a FIPS module. The permanent error of the Jitter RNG is translated as a FIPS module error. In this case, the entire FIPS module must cease operation. This is implemented in the kernel by invoking panic(). The patch also fixes an off-by-one in the RCT cutoff value which is now set to 30 instead of 31. This is because the counting of the values starts with 0. Reviewed-by:
Vladis Dronov <vdronov@redhat.com> Signed-off-by:
Stephan Mueller <smueller@chronox.de> Reviewed-by:
Marcelo Henrique Cerri <marcelo.cerri@canonical.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
- 31 Mar, 2023 5 commits
-
-
Christophe JAILLET authored
Use devm_clk_get_optional_enabled() instead of hand writing it. This saves some loC and improves the semantic. update the error handling path and the remove function accordingly. Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Krzysztof Kozlowski authored
Mark the of_device_id table as maybe_unused. This fixes a W=1 warning: drivers/crypto/img-hash.c:930:34: error: ‘img_hash_match’ defined but not used [-Werror=unused-const-variable=] Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Suman Anna authored
The SA2UL Crypto driver provides support for couple of DES3 algos "cbc(des3_ede)" and "ecb(des3_ede)", and enabling the crypto selftest throws the following errors (as seen on K3 J721E SoCs): saul-crypto 4e00000.crypto: Error allocating fallback algo cbc(des3_ede) alg: skcipher: failed to allocate transform for cbc-des3-sa2ul: -2 saul-crypto 4e00000.crypto: Error allocating fallback algo ecb(des3_ede) alg: skcipher: failed to allocate transform for ecb-des3-sa2ul: -2 Fix this by selecting CRYPTO_DES which was missed while adding base driver support. Fixes: 7694b6ca ("crypto: sa2ul - Add crypto driver") Signed-off-by:
Suman Anna <s-anna@ti.com> Signed-off-by:
Jayesh Choudhary <j-choudhary@ti.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Herbert Xu authored
The utilities have historically resided in algapi.h as they were first used internally before being exported. Move them into a new header file so external users don't see internal API details. Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Christophe JAILLET authored
According to the comment at the end of the 'for' loop just a few lines below, it looks needed to clear 'desc'. So it should also be cleared for the first iteration. Move the memset() to the beginning of the loop to be safe. Fixes: 281922a1 ("crypto: caam - add support for SEC v5.x RNG4") Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by:
Gaurav Jain <gaurav.jain@nxp.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-