- 20 Apr, 2023 21 commits
-
-
Danny Tsen authored
Remove Power10 dependency in Kconfig and detect Power10 feature at runtime. Signed-off-by:
Danny Tsen <dtsen@linux.ibm.com> Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc) Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
David Howells authored
Add some test vectors for 128-bit cmac(camellia) as found in draft-kato-ipsec-camellia-cmac96and128-01 section 6.2. The document also shows vectors for camellia-cmac-96, and for VK with a length greater than 16, but I'm not sure how to express those in testmgr. This also leaves cts(cbc(camellia)) untested, but I can't seem to find any tests for that that I could put into testmgr. Signed-off-by:
David Howells <dhowells@redhat.com> cc: Herbert Xu <herbert@gondor.apana.org.au> cc: Chuck Lever <chuck.lever@oracle.com> cc: Scott Mayhew <smayhew@redhat.com> cc: linux-nfs@vger.kernel.org cc: linux-crypto@vger.kernel.org Link: https://datatracker.ietf.org/doc/pdf/draft-kato-ipsec-camellia-cmac96and128-01Signed-off-by:
-
Herbert Xu authored
Allow cryptd hashes to be cloned. The underlying hash will be cloned. Signed-off-by: -
Herbert Xu authored
The cryptd hash template was still using the obsolete cra_init/cra_exit interface. Make it use the modern ahash init_tfm/exit_tfm instead. Signed-off-by:
Simon Horman <simon.horman@corigine.com> Signed-off-by:
-
Herbert Xu authored
Allow hmac to be cloned. The underlying hash can be used directly with a reference count. Signed-off-by: -
Herbert Xu authored
This patch adds the helpers crypto_clone_ahash and crypto_clone_shash. They are the hash-specific counterparts of crypto_clone_tfm. This allows code paths that cannot otherwise allocate a hash tfm object to do so. Once a new tfm has been obtained its key could then be changed without impacting other users. Note that only algorithms that implement clone_tfm can be cloned. However, all keyless hashes can be cloned by simply reusing the tfm object. Signed-off-by:
-
Herbert Xu authored
This patch adds the helper crypto_clone_tfm. The purpose is to allocate a tfm object with GFP_ATOMIC. As we cannot sleep, the object has to be cloned from an existing tfm object. This allows code paths that cannot otherwise allocate a crypto_tfm object to do so. Once a new tfm has been obtained its key could then be changed without impacting other users. Signed-off-by:
-
Herbert Xu authored
Add a crypto_tfm_get interface to allow tfm objects to be shared. They can still be freed in the usual way. This should only be done with tfm objects with no keys. You must also not modify the tfm flags in any way once it becomes shared. Signed-off-by:
-
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:
-
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 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 authored
Prefer RIP-relative addressing where possible, which removes the need for boot time relocation fixups. Signed-off-by:
-
Ard Biesheuvel authored
Prefer RIP-relative addressing where possible, which removes the need for boot time relocation fixups. Signed-off-by:
-
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:
-
Ard Biesheuvel authored
Prefer RIP-relative addressing where possible, which removes the need for boot time relocation fixups. Signed-off-by:
-
Ard Biesheuvel authored
Prefer RIP-relative addressing where possible, which removes the need for boot time relocation fixups. Co-developed-by:
-
Ard Biesheuvel authored
Prefer RIP-relative addressing where possible, which removes the need for boot time relocation fixups. Co-developed-by:
-
Ard Biesheuvel authored
Prefer RIP-relative addressing where possible, which removes the need for boot time relocation fixups. Co-developed-by:
-
Ard Biesheuvel authored
Prefer RIP-relative addressing where possible, which removes the need for boot time relocation fixups. Signed-off-by:
-
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 authored
Prefer RIP-relative addressing where possible, which removes the need for boot time relocation fixups. Signed-off-by:
-
- 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:
-
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:
-
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:
Varun Sethi <v.sethi@nxp.com> Reviewed-by:
-
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:
-
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:
-
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 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:
-
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:
Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by:
-
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:
-
- 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:
-
- 06 Apr, 2023 9 commits
-
-
David Yang authored
HiSTB TRNG are found on some HiSilicon STB SoCs. Signed-off-by:
David Yang <mmyangfl@gmail.com> Signed-off-by:
-
Ryan Wanner authored
Change blocksize to match the cfb(aes) generic implementation. Signed-off-by:
Ryan Wanner <Ryan.Wanner@microchip.com> Signed-off-by:
-
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 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 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:
-
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:
-
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:
Corentin LABBE <clabbe@baylibre.com> Signed-off-by:
-
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:
Daniele Alessandrelli <daniele.alessandrelli@intel.com> Signed-off-by:
-
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:
-
