Re: [PATCH v5 3/5] crypto: expose elliptic curve parameters as Crypto APIs
On Thu, Dec 24, 2020 at 02:08:25PM +0800, Meng Yu wrote: > Move elliptic curves definition to 'include/crypto/ecc_curve_defs.h', > so all can use it, > > Signed-off-by: Meng Yu > Reviewed-by: Zaibo Xu > --- > crypto/ecc.c| 1 - > crypto/ecc.h| 37 + > crypto/ecc_curve_defs.h | 57 - > crypto/ecrdsa_defs.h| 2 +- > include/crypto/ecc_curve_defs.h | 92 > + > 5 files changed, 95 insertions(+), 94 deletions(-) > delete mode 100644 crypto/ecc_curve_defs.h > create mode 100644 include/crypto/ecc_curve_defs.h This conflicts with https://patchwork.kernel.org/project/linux-crypto/patch/20201217172101.381772-3-daniele.alessandre...@linux.intel.com/ Please discuss with each other on how you would like to proceed. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 1/6] drivers: crypto: qce: sha: Restore/save sha1_state/sha256_state with qce_sha_reqctx in export/import
On Fri, Dec 18, 2020 at 10:30:22PM -0500, Thara Gopinath wrote: > Export and import interfaces save and restore partial transformation > states. The partial states were being stored and restored in struct > sha1_state for sha1/hmac(sha1) transformations and sha256_state for > sha256/hmac(sha256) transformations.This led to a bunch of corner cases > where improper state was being stored and restored. A few of the corner > cases that turned up during testing are: > > - wrong byte_count restored if export/import is called twice without h/w > transaction in between > - wrong buflen restored back if the pending buffer > length is exactly the block size. > - wrong state restored if buffer length is 0. > > To fix these issues, save and restore the entire qce_sha_rctx structure > instead of parts of it in sha1_state and sha256_state structures. > This in turn simplifies the export and import apis. > > Signed-off-by: Thara Gopinath > --- > drivers/crypto/qce/sha.c | 93 > 1 file changed, 8 insertions(+), 85 deletions(-) How is this safe when the reqctx structure contains pointers? Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v2] hwrng: fix khwrng lifecycle
On Wed, Dec 16, 2020 at 11:59:06AM +0100, Luca Dariz wrote:
>
> @@ -432,12 +433,15 @@ static int hwrng_fillfn(void *unused)
> {
> long rc;
>
> + complete(&hwrng_started);
> while (!kthread_should_stop()) {
> struct hwrng *rng;
>
> rng = get_current_rng();
> - if (IS_ERR(rng) || !rng)
> - break;
> + if (IS_ERR(rng) || !rng) {
> + msleep_interruptible(10);
> + continue;
Please fix this properly with reference counting.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: x86/crc32c-intel - Don't match some Zhaoxin CPUs
On Tue, Dec 15, 2020 at 06:28:11PM +0800, Tony W Wang-oc wrote: > The driver crc32c-intel match CPUs supporting X86_FEATURE_XMM4_2. > On platforms with Zhaoxin CPUs supporting this X86 feature, when > crc32c-intel and crc32c-generic are both registered, system will > use crc32c-intel because its .cra_priority is greater than > crc32c-generic. > > When doing lmbench3 Create and Delete file test on partitions with > ext4 enabling metadata checksum, found using crc32c-generic driver > could get about 20% performance gain than using the driver crc32c-intel > on some Zhaoxin CPUs. > > This case expect to use crc32c-generic driver for these Zhaoxin CPUs > to get performance gain, so remove these Zhaoxin CPUs support from > crc32c-intel. > > Signed-off-by: Tony W Wang-oc > --- > arch/x86/crypto/crc32c-intel_glue.c | 21 +++-- > 1 file changed, 19 insertions(+), 2 deletions(-) This does not seem to address the latest comment from hpa. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v2 0/6] crypto: hisilicon - enable new algorithms of SEC
On Thu, Dec 10, 2020 at 07:10:01PM +0800, Longfang Liu wrote: > Add support for new algorithms of SEC accelerator on Kunpeng930, > the driver and test case needs to be updated > > Longfang Liu (5): > crypto: hisilicon/sec - add new type of sqe for Kunpeng930 > crypto: hisilicon/sec - add new skcipher mode for SEC > crypto: hisilicon/sec - add new AEAD mode for SEC Did you run the fuzz tests on these additions? Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
[GIT PULL] Crypto Fixes for 5.11
Hi Linus: This push fixes a number of autobuild failures due to missing Kconfig dependencies. The following changes since commit 93cebeb1c21a65b92636aaa278a32fbc0415ec67: crypto: qat - add capability detection logic in qat_4xxx (2020-12-11 21:54:16 +1100) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git linus for you to fetch changes up to c0e583ab2016de8dedfb73934d4c4e8ff5bd896c: crypto: qat - add CRYPTO_AES to Kconfig dependencies (2020-12-23 18:45:23 +1100) Daniele Alessandrelli (1): crypto: keembay - Add dependency on HAS_IOMEM Geert Uytterhoeven (1): crypto: keembay - CRYPTO_DEV_KEEMBAY_OCS_AES_SM4 should depend on ARCH_KEEMBAY Marco Chiappero (1): crypto: qat - add CRYPTO_AES to Kconfig dependencies drivers/crypto/keembay/Kconfig | 5 +++-- drivers/crypto/qat/Kconfig | 1 + 2 files changed, 4 insertions(+), 2 deletions(-) Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: dm-crypt with no_read_workqueue and no_write_workqueue + btrfs scrub = BUG()
On Wed, Dec 23, 2020 at 04:37:34PM +0100, Maciej S. Szmigiero wrote: > > It looks like to me that the skcipher API might not be safe to > call from a softirq context, after all. skcipher is safe to use in a softirq. The problem is only in dm-crypt where it tries to allocate memory with GFP_NOIO. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: qat - add CRYPTO_AES to Kconfig dependencies
On Wed, Dec 23, 2020 at 07:39:46PM +0100, Ard Biesheuvel wrote: > > This should be 'select CRYPTO_LIB_AES' Please send a follow-up. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v2] crypto: arm/chacha-neon - add missing counter increment
On Mon, Dec 14, 2020 at 12:39:29PM -0800, Eric Biggers wrote: > > That doesn't make sense, given that most algorithms don't implement it... It doesn't matter for chacha, but it's still true for the Crypto API in general. Yes I know that lots of algorithms get it wrong, but it is on my list of things to fix. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: qat - add CRYPTO_AES to Kconfig dependencies
On Tue, Dec 22, 2020 at 01:00:24PM +, Marco Chiappero wrote:
> This patch includes a missing dependency (CRYPTO_AES) which may
> lead to an "undefined reference to `aes_expandkey'" linking error.
>
> Fixes: 5106dfeaeabe ("crypto: qat - add AES-XTS support for QAT GEN4 devices")
> Reported-by: kernel test robot
> Signed-off-by: Marco Chiappero
> ---
> drivers/crypto/qat/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: keembay-ocs-aes - Add dependency on HAS_IOMEM
On Thu, Dec 17, 2020 at 04:35:10PM +, Daniele Alessandrelli wrote:
> From: Daniele Alessandrelli
>
> Add dependency for CRYPTO_DEV_KEEMBAY_OCS_AES_SM4 on HAS_IOMEM to
> prevent build failures.
>
> Fixes: 88574332451380f4 ("crypto: keembay - Add support for Keem Bay OCS
> AES/SM4")
> Reported-by: kernel test robot
> Signed-off-by: Daniele Alessandrelli
> ---
> drivers/crypto/keembay/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: CRYPTO_DEV_KEEMBAY_OCS_AES_SM4 should depend on ARCH_KEEMBAY
On Wed, Dec 16, 2020 at 02:14:59PM +0100, Geert Uytterhoeven wrote:
> The Intel Keem Bay Offload and Crypto Subsystem (OCS) is only present on
> Intel Keem Bay SoCs. Hence add a dependency on ARCH_KEEMBAY, to prevent
> asking the user about this driver when configuring a kernel without
> Intel Keem Bay platform support.
>
> While at it, fix a misspelling of "cipher".
>
> Fixes: 88574332451380f4 ("crypto: keembay - Add support for Keem Bay OCS
> AES/SM4")
> Signed-off-by: Geert Uytterhoeven
> ---
> drivers/crypto/keembay/Kconfig | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [RFC PATCH 0/5] running kernel mode SIMD with softirqs disabled
On Fri, Dec 18, 2020 at 06:01:01PM +0100, Ard Biesheuvel wrote: > > Questions: > - what did I miss or break horribly? > - does any of this matter for RT? AIUI, RT runs softirqs from a dedicated > kthread, so I don't think it cares. > - what would be a reasonable upper bound to keep softirqs disabled? I suppose > 100s of cycles or less is overkill, but I'm not sure how to derive a better > answer. > - could we do the same on x86, now that kernel_fpu_begin/end is no longer > expensive? If this approach works not only would it allow us to support the synchronous users better, it would also allow us to remove loads of cruft in the Crypto API that exist solely to support these SIMD code paths. So I eagerly await the assessment of the scheduler/RT folks on this approach. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [f2fs-dev] [PATCH v7 0/3] Update to zstd-1.4.6
On Wed, Dec 16, 2020 at 12:48:51AM +, Nick Terrell wrote: > > Thanks for the advice! The first zstd patches went through Herbert’s tree, > which is > why I’ve sent them this way. Sorry, but I'm not touch these patches as Christoph's objections don't seem to have been addressed. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v2] crypto: aesni - add ccm(aes) algorithm implementation
On Tue, Dec 15, 2020 at 09:55:37AM +0100, Ard Biesheuvel wrote: > > So the question is then how granular these kernel mode SIMD regions > need to be to avoid excessive latencies in softirq handling. Can you get some real world numbers on what the latency is like? Then we could take it to the scheduler folks and see if they're OK with it. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
[GIT PULL] Crypto Update for 5.11
o: qat - remove hardcoded bank irq clear flag mask crypto: qat - call functions in adf_sriov if available crypto: qat - remove unnecessary void* casts crypto: qat - change return value in adf_cfg_add_key_value_param() crypto: qat - change return value in adf_cfg_key_val_get() crypto: qat - refactor qat_crypto_create_instances() crypto: qat - refactor qat_crypto_dev_config() crypto: qat - allow for instances in different banks crypto: qat - extend ae_mask crypto: qat - support for mof format in fw loader crypto: qat - target fw images to specific AEs crypto: qat - add hook to initialize vector routing table crypto: qat - add qat_4xxx driver Gustavo A. R. Silva (1): crypto: ccree - Fix fall-through warnings for Clang Herbert Xu (10): lib/mpi: Remove unused scalar_copied crypto: sa2ul - Reduce stack usage crypto: cavium/nitrox - Fix sparse warnings crypto: lib/curve25519 - Move selftest prototype into header file crypto: mips/octeon - Fix sparse endianness warnings crypto: powerpc/sha256-spe - Fix sparse endianness warning crypto: sparc - Fix sparse endianness warnings crypto: lib/blake2s - Move selftest prototype into header file hwrng: ks-sa - Add dependency on IOMEM and OF crypto: cpt - Fix sparse warnings in cptpf Horia Geantă (3): crypto: arm/aes-neonbs - fix usage of cbc(aes) fallback crypto: caam - fix printing on xts fallback allocation error path crypto: caam/qi - simplify error path for context allocation Iuliana Prodan (1): crypto: caam - enable crypto-engine retry mechanism Jack Xu (31): crypto: qat - fix status check in qat_hal_put_rel_rd_xfer() crypto: qat - fix CSR access crypto: qat - fix error message crypto: qat - remove unnecessary parenthesis crypto: qat - introduce additional parenthesis crypto: qat - rename qat_uclo_del_uof_obj() crypto: qat - add support for relative FW ucode loading crypto: qat - change type for ctx_mask crypto: qat - change micro word data mask crypto: qat - refactor AE start crypto: qat - remove global CSRs helpers crypto: qat - move defines to header files crypto: qat - refactor qat_uclo_set_ae_mode() crypto: qat - refactor long expressions crypto: qat - introduce chip info structure crypto: qat - replace check based on DID crypto: qat - add next neighbor to chip_info crypto: qat - add support for lm2 and lm3 crypto: qat - add local memory size to chip info crypto: qat - add reset CSR and mask to chip info crypto: qat - add clock enable CSR to chip info crypto: qat - add wake up event to chip info crypto: qat - add misc control CSR to chip info crypto: qat - add check for null pointer crypto: qat - use ae_mask crypto: qat - add CSS3K support crypto: qat - add FCU CSRs to chip info crypto: qat - allow to target specific AEs crypto: qat - add support for shared ustore crypto: qat - add support for broadcasting mode crypto: qat - add gen4 firmware loader Jason A. Donenfeld (1): crypto: Kconfig - CRYPTO_MANAGER_EXTRA_TESTS requires the manager Kai Ye (1): crypto: hisilicon/sec2 - Fix aead authentication setting key error Longfang Liu (2): crypto: hisilicon - delete unused structure member variables crypto: hisilicon - fixes some coding style Marco Chiappero (5): crypto: qat - update IV in software crypto: qat - add support for capability detection crypto: qat - add AES-CTR support for QAT GEN4 devices crypto: qat - add AES-XTS support for QAT GEN4 devices crypto: qat - add capability detection logic in qat_4xxx Mike Healy (1): crypto: keembay - Add support for Keem Bay OCS AES/SM4 Nathan Chancellor (1): crypto: crypto4xx - Replace bitwise OR with logical OR in crypto4xx_build_pd Nigel Christian (1): hwrng: imx-rngc - irq already prints an error Shiju Jose (1): crypto: hisilicon - Fix doc warnings in sgl.c and qm.c Thara Gopinath (2): crypto: qce - Enable support for crypto engine on sdm845 crypto: qce - Fix SHA result buffer corruption issues Tianjia Zhang (1): crypto: sm2 - remove unnecessary reset operations Tom Rix (4): crypto: atmel-sha - remove unneeded break crypto: cavium/nitrox - remove unneeded semicolon crypto: qat - remove unneeded semicolon crypto: seed - remove trailing semicolon in macro definition Uros Bizjak (3): crypto: aesni - Use TEST %reg,%reg instead of CMP $0,%reg crypto: x86/sha512 - Use TEST %reg,%reg instead of CMP $0,%reg crypto: x86/poly1305 - Use TEST %reg,%reg instead of CMP $0,%reg Weili Qian (12): crypto: hisilicon/qm - numbers are replaced by macros crypto: hisilicon/qm - modify the return type of function crypto: hisilicon/qm - mo
Re: [PATCH v2] crypto: arm/chacha-neon - add missing counter increment
On Sun, Dec 13, 2020 at 06:23:06PM -0800, Eric Biggers wrote: > > This part doesn't seem to be true, since the chacha implementations don't > implement the "output IV" thing. It's only cbc and ctr that do (or at least > those are the only algorithms it's tested for). If this algorithm can be used through algif_skcipher then it will be making use of the output IV. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 0/3] crypto: qat - add support for AES-CTR and AES-XTS in qat_4xxx
On Tue, Dec 01, 2020 at 02:24:48PM +, Giovanni Cabiddu wrote: > This set adds support for AES-CTR and AES-XTS for QAT GEN4 devices and > adds logic to detect and enable crypto capabilities in the qat_4xxx > driver. > > Marco Chiappero (3): > crypto: qat - add AES-CTR support for QAT GEN4 devices > crypto: qat - add AES-XTS support for QAT GEN4 devices > crypto: qat - add capability detection logic in qat_4xxx > > .../crypto/qat/qat_4xxx/adf_4xxx_hw_data.c| 24 > .../crypto/qat/qat_4xxx/adf_4xxx_hw_data.h| 11 ++ > drivers/crypto/qat/qat_4xxx/adf_drv.c | 3 + > drivers/crypto/qat/qat_common/icp_qat_fw_la.h | 7 ++ > drivers/crypto/qat/qat_common/icp_qat_hw.h| 17 ++- > drivers/crypto/qat/qat_common/qat_algs.c | 111 -- > 6 files changed, 165 insertions(+), 8 deletions(-) All applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 2/3] crypto: qat - add AES-XTS support for QAT GEN4 devices
On Fri, Dec 11, 2020 at 11:42:08AM +0100, Ard Biesheuvel wrote: > > I think this is a valid use of a bare cipher - it lives as long as the > TFM itself, and may be used on a hot path. > > I need to respin the bare cipher change I sent the other day anyway, > so I'll make sure this driver gets the right treatment as well (which > shouldn't cause any conflicts so the changes can be merged in any > order) Thanks for looking into this Ard! -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: hisilicon/trng replace atomic_add_return()
On Tue, Dec 01, 2020 at 02:50:18PM +0800, Yejune Deng wrote: > a set of atomic_inc_return() looks more neater > > Signed-off-by: Yejune Deng > --- > drivers/crypto/hisilicon/trng/trng.c | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) All applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: atmel-i2c - select CONFIG_BITREVERSE
On Fri, Dec 04, 2020 at 12:20:04AM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> The bitreverse helper is almost always built into the kernel,
> but in a rare randconfig build it is possible to hit a case
> in which it is a loadable module while the atmel-i2c driver
> is built-in:
>
> arm-linux-gnueabi-ld: drivers/crypto/atmel-i2c.o: in function
> `atmel_i2c_checksum':
> atmel-i2c.c:(.text+0xa0): undefined reference to `byte_rev_table'
>
> Add one more 'select' statement to prevent this.
>
> Fixes: 11105693fa05 ("crypto: atmel-ecc - introduce Microchip / Atmel ECC
> driver")
> Signed-off-by: Arnd Bergmann
> ---
> drivers/crypto/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 0/2] crypto: Add Keem Bay OCS AES/SM4 driver
On Thu, Nov 26, 2020 at 11:51:46AM +, Daniele Alessandrelli wrote: > The Intel Keem Bay SoC has an Offload Crypto Subsystem (OCS) featuring a > crypto engine for accelerating AES/SM4 operations. > > This driver adds support for such hardware thus enabling hardware > acceleration for the following transformations on the Intel Keem Bay SoC: > > - ecb(aes), cbc(aes), ctr(aes), cts(cbc(aes)), gcm(aes) and cbc(aes); > supported for 128-bit and 256-bit keys. > > - ecb(sm4), cbc(sm4), ctr(sm4), cts(cbc(sm4)), gcm(sm4) and cbc(sm4); > supported for 128-bit keys. > > The driver passes crypto manager self-tests, including the extra tests > (CRYPTO_MANAGER_EXTRA_TESTS=y). > > Note: this driver is different from the Keem Bay OCS HCU driver previously > submitted. Keem Bay OCS HCU provides hardware-accelerated ahash, while > Keem Bay AES/SM4 (i.e., this driver) provides hardware-accelerated > skcipher and aead. > > > Daniele Alessandrelli (1): > dt-bindings: Add Keem Bay OCS AES bindings > > Mike Healy (1): > crypto: keembay-ocs-aes: Add support for Keem Bay OCS AES/SM4 > > .../crypto/intel,keembay-ocs-aes.yaml | 45 + > MAINTAINERS | 10 + > drivers/crypto/Kconfig|2 + > drivers/crypto/Makefile |1 + > drivers/crypto/keembay/Kconfig| 39 + > drivers/crypto/keembay/Makefile |5 + > drivers/crypto/keembay/keembay-ocs-aes-core.c | 1713 + > drivers/crypto/keembay/ocs-aes.c | 1489 ++ > drivers/crypto/keembay/ocs-aes.h | 129 ++ > 9 files changed, 3433 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/crypto/intel,keembay-ocs-aes.yaml > create mode 100644 drivers/crypto/keembay/Kconfig > create mode 100644 drivers/crypto/keembay/Makefile > create mode 100644 drivers/crypto/keembay/keembay-ocs-aes-core.c > create mode 100644 drivers/crypto/keembay/ocs-aes.c > create mode 100644 drivers/crypto/keembay/ocs-aes.h All applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 0/5] crypto: caam - avoid allocating memory at crypto request runtime
On Thu, Dec 10, 2020 at 10:28:35AM +0200, Horia Geantă wrote: > > Moving the memory allocations from caam driver into the generic crypto API > has the side effect of dropping the GFP_DMA allocation flag. > > For cases when caam device is limited to 32-bit address space and > there's no IOMMU, this could lead to DMA API using bounce buffering. > > We need to measure the performance impact of this change before deciding > what we should do next. This only applies to the control data, right? The actual data being operated on surely is the most important factor. In any case, did you respond to Ard's concern about potentially exhausting DMA memory? Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 2/3] crypto: qat - add AES-XTS support for QAT GEN4 devices
On Tue, Dec 01, 2020 at 02:24:50PM +, Giovanni Cabiddu wrote:
>
> @@ -1293,6 +1366,12 @@ static int qat_alg_skcipher_init_xts_tfm(struct
> crypto_skcipher *tfm)
> if (IS_ERR(ctx->ftfm))
> return PTR_ERR(ctx->ftfm);
>
> + ctx->tweak = crypto_alloc_cipher("aes", 0, 0);
> + if (IS_ERR(ctx->tweak)) {
> + crypto_free_skcipher(ctx->ftfm);
> + return PTR_ERR(ctx->tweak);
> + }
> +
> reqsize = max(sizeof(struct qat_crypto_request),
> sizeof(struct skcipher_request) +
> crypto_skcipher_reqsize(ctx->ftfm));
This may clash with the work that Ard is doing on simpler ciphers.
So I think this should switch over to using the library interface
for aes. What do you think Ard?
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v2] crypto: aesni - add ccm(aes) algorithm implementation
On Thu, Dec 10, 2020 at 01:03:56PM +0100, Ard Biesheuvel wrote:
>
> But we should probably start policing this a bit more. For instance, we now
> have
>
> drivers/net/macsec.c:
>
> /* Pick a sync gcm(aes) cipher to ensure order is preserved. */
> tfm = crypto_alloc_aead("gcm(aes)", 0, CRYPTO_ALG_ASYNC);
>
> (btw the comment is bogus, right?)
>
> TLS_SW does the same thing in net/tls/tls_device_fallback.c.
Short of us volunteering to write code for every user out there
I don't see a way out.
> Async is obviously needed for h/w accelerators, but could we perhaps
> do better for s/w SIMD algorithms? Those are by far the most widely
> used ones.
If you can come up with a way that avoids the cryptd model without
using a fallback obviously that would be the ultimate solution.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v2] crypto: aesni - add ccm(aes) algorithm implementation
On Thu, Dec 10, 2020 at 08:30:47AM +0100, Ard Biesheuvel wrote: > > I would argue that these are orthogonal. My patch improves both the > accelerated and the fallback path, given that the latter does not have > to walk the input data twice anymore, and go through 3 layers of > templates and the associated indirect calls for each 16 bytes of > input. As I told your before, your patch introduces a new model into aesni that is different to every other algorithm there for the sole purpose of catering for legacy hardware in a subsystem that refuses to do the right thing. That is not acceptable. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v2] crypto: aesni - add ccm(aes) algorithm implementation
On Thu, Dec 10, 2020 at 01:18:12AM +0100, Ard Biesheuvel wrote: > > One thing I realized just now is that in the current situation, all > the synchronous skciphers already degrade like this. > > I.e., in Ben's case, without the special ccm implementation, ccm(aes) > will resolve to ccm(ctr(aesni),cbcmac(aesni)), which is instantiated > as a sync skcipher using the ctr and ccm/cbcmac templates built on top > of the AES-NI cipher (not skcipher). This cipher will also fall back > to suboptimal scalar code if the SIMD is in use in process context. Sure, your patch is not making it any worse. But I don't think the extra code is worth it considering that you're still going to be running into that slow fallback path all the time. Much better to fix the wireless code to actually go async. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 2/5] crypto: hisilicon/sec - add new type of sqe for Kunpeng930
On Mon, Dec 07, 2020 at 03:46:28PM +0800, liulongfang wrote: > > I need to use "__packed __aligned(n)" to make sure the structure length is > normal. > Is it possible to use "__packed __aligned(n)" in the kernel? I don't see why not. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 2/5] crypto: hisilicon/sec - add new type of sqe for Kunpeng930
On Mon, Dec 07, 2020 at 11:43:38AM +0800, liulongfang wrote: > > Can I use __attribute__((aligned(n))) instead of #pragma pack(n)? We normally just use __aligned(n) in the kernel. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 0/5] crypto: hisilicon - add some new algorithms
On Mon, Dec 07, 2020 at 09:20:05AM +0800, liulongfang wrote: > > Did any test case tests fail? You tell me :) If it passed all of the tests in your testing, please state that in the cover letter or in one of the patches. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Why the auxiliary cipher in gss_krb5_crypto.c?
On Fri, Dec 04, 2020 at 06:35:48PM +0100, Ard Biesheuvel wrote: > > Herbert recently made some changes for MSG_MORE support in the AF_ALG > code, which permits a skcipher encryption to be split into several > invocations of the skcipher layer without the need for this complexity > on the side of the caller. Maybe there is a way to reuse that here. > Herbert? Yes this was one of the reasons I was persuing the continuation work. It should allow us to kill the special case for CTS in the krb5 code. Hopefully I can get some time to restart work on this soon. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: aegis128 - avoid spurious references crypto_aegis128_update_simd
On Mon, Nov 30, 2020 at 01:26:20PM +0100, Ard Biesheuvel wrote: > Geert reports that builds where CONFIG_CRYPTO_AEGIS128_SIMD is not set > may still emit references to crypto_aegis128_update_simd(), which > cannot be satisfied and therefore break the build. These references > only exist in functions that can be optimized away, but apparently, > the compiler is not always able to prove this. > > So add some explicit checks for CONFIG_CRYPTO_AEGIS128_SIMD to help the > compiler figure this out. > > Tested-by: Geert Uytterhoeven > Signed-off-by: Ard Biesheuvel > --- > crypto/aegis128-core.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: remove trailing semicolon in macro definition
On Fri, Nov 27, 2020 at 08:23:45AM -0800, t...@redhat.com wrote: > From: Tom Rix > > The macro use will already have a semicolon. > > Signed-off-by: Tom Rix > --- > crypto/seed.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: x86/poly1305-intel: Use TEST %reg,%reg instead of CMP $0,%reg
On Fri, Nov 27, 2020 at 11:18:12AM +0100, Uros Bizjak wrote: > CMP $0,%reg can't set overflow flag, so we can use shorter TEST %reg,%reg > instruction when only zero and sign flags are checked (E,L,LE,G,GE > conditions). > > Signed-off-by: Uros Bizjak > Cc: Herbert Xu > Cc: Borislav Petkov > Cc: "H. Peter Anvin" > --- > arch/x86/crypto/poly1305-x86_64-cryptogams.pl | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: ecdh - avoid unaligned accesses in ecdh_set_secret()
On Tue, Nov 24, 2020 at 11:47:19AM +0100, Ard Biesheuvel wrote: > ecdh_set_secret() casts a void* pointer to a const u64* in order to > feed it into ecc_is_key_valid(). This is not generally permitted by > the C standard, and leads to actual misalignment faults on ARMv6 > cores. In some cases, these are fixed up in software, but this still > leads to performance hits that are entirely avoidable. > > So let's copy the key into the ctx buffer first, which we will do > anyway in the common case, and which guarantees correct alignment. > > Cc: > Signed-off-by: Ard Biesheuvel > --- > crypto/ecdh.c | 9 + > 1 file changed, 5 insertions(+), 4 deletions(-) Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: x86/sha512-intel: Use TEST %reg,%reg instead of CMP $0,%reg
On Fri, Nov 27, 2020 at 10:59:43AM +0100, Uros Bizjak wrote: > CMP $0,%reg can't set overflow flag, so we can use shorter TEST %reg,%reg > instruction when only zero and sign flags are checked (E,L,LE,G,GE > conditions). > > Signed-off-by: Uros Bizjak > Cc: Herbert Xu > Cc: Borislav Petkov > Cc: "H. Peter Anvin" > --- > arch/x86/crypto/sha512-avx-asm.S | 2 +- > arch/x86/crypto/sha512-ssse3-asm.S | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: x86/aesni-intel: Use TEST %reg,%reg instead of CMP $0,%reg
On Fri, Nov 27, 2020 at 10:44:52AM +0100, Uros Bizjak wrote: > CMP $0,%reg can't set overflow flag, so we can use shorter TEST %reg,%reg > instruction when only zero and sign flags are checked (E,L,LE,G,GE > conditions). > > Signed-off-by: Uros Bizjak > Cc: Herbert Xu > Cc: Borislav Petkov > Cc: "H. Peter Anvin" > --- > arch/x86/crypto/aesni-intel_asm.S| 20 ++-- > arch/x86/crypto/aesni-intel_avx-x86_64.S | 20 ++-- > 2 files changed, 20 insertions(+), 20 deletions(-) Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v2] crypto: arm/aes-ce - work around Cortex-A57/A72 silion errata
On Thu, Nov 26, 2020 at 08:49:07AM +0100, Ard Biesheuvel wrote: > ARM Cortex-A57 and Cortex-A72 cores running in 32-bit mode are affected > by silicon errata #1742098 and #1655431, respectively, where the second > instruction of a AES instruction pair may execute twice if an interrupt > is taken right after the first instruction consumes an input register of > which a single 32-bit lane has been updated the last time it was modified. > > This is not such a rare occurrence as it may seem: in counter mode, only > the least significant 32-bit word is incremented in the absence of a > carry, which makes our counter mode implementation susceptible to these > errata. > > So let's shuffle the counter assignments around a bit so that the most > recent updates when the AES instruction pair executes are 128-bit wide. > > [0] ARM-EPM-049219 v23 Cortex-A57 MPCore Software Developers Errata Notice > [1] ARM-EPM-012079 v11.0 Cortex-A72 MPCore Software Developers Errata Notice > > Cc: # v5.4+ > Signed-off-by: Ard Biesheuvel > --- > v2: - add comment block describing the erratum and how it is being worked > around > - mention A57 as well as A72, as both are affected > > arch/arm/crypto/aes-ce-core.S | 32 ++-- > 1 file changed, 22 insertions(+), 10 deletions(-) Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 0/5] crypto: hisilicon - add some new algorithms
On Thu, Nov 26, 2020 at 10:18:01AM +0800, Longfang Liu wrote: > As the new Kunpeng930 supports some new algorithms, > the driver needs to be updated > > Longfang Liu (4): > crypto: hisilicon/sec - add new type of sqe for Kunpeng930 > crypto: hisilicon/sec - add new skcipher mode for SEC > crypto: hisilicon/sec - add new AEAD mode for SEC > crypto: hisilicon/sec - fixes some coding style > > Meng Yu (1): > crypto: hisilicon/hpre - add version adapt to new algorithms Please include details on whether this has been tested with the self-tests, including the extra fuzz tests. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 2/5] crypto: hisilicon/sec - add new type of sqe for Kunpeng930
On Thu, Nov 26, 2020 at 10:18:03AM +0800, Longfang Liu wrote:
>
> diff --git a/drivers/crypto/hisilicon/sec2/sec_crypto.h
> b/drivers/crypto/hisilicon/sec2/sec_crypto.h
> index 0e933e7..712176b 100644
> --- a/drivers/crypto/hisilicon/sec2/sec_crypto.h
> +++ b/drivers/crypto/hisilicon/sec2/sec_crypto.h
> @@ -211,6 +219,167 @@ struct sec_sqe {
> struct sec_sqe_type2 type2;
> };
>
> +#pragma pack(4)
Please don't use pragma pack. Instead add the attributes as
needed to each struct or member.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] implements ecdsa 256, 384 and 521 alghorithm in akcipher model; change pcks7 and x509 to load certificates with ecdsa; increment testmgr to test ecdsa algo and finally allows signature and
On Wed, Nov 25, 2020 at 11:03:08PM -0300, Saulo Alessandre wrote: > From: Saulo Alessandre > > Signed-off-by: Saulo Alessandre > --- > Documentation/admin-guide/module-signing.rst | 10 + > crypto/Kconfig | 12 + > crypto/Makefile | 7 + > crypto/asymmetric_keys/pkcs7_parser.c| 7 +- > crypto/asymmetric_keys/pkcs7_verify.c| 5 +- > crypto/asymmetric_keys/public_key.c | 30 +- > crypto/asymmetric_keys/x509_cert_parser.c| 30 +- > crypto/ecc.c | 228 - > crypto/ecc.h | 62 ++- > crypto/ecc_curve_defs.h | 82 +++ > crypto/ecdsa.c | 508 +++ > crypto/ecdsa_params.asn1 | 1 + > crypto/ecdsa_signature.asn1 | 6 + > crypto/testmgr.c | 17 +- > crypto/testmgr.h | 78 +++ > include/crypto/ecdh.h| 2 + > include/linux/oid_registry.h | 12 + > lib/oid_registry.c | 108 +++- > 18 files changed, 1146 insertions(+), 59 deletions(-) > create mode 100644 crypto/ecdsa.c > create mode 100644 crypto/ecdsa_params.asn1 > create mode 100644 crypto/ecdsa_signature.asn1 Please split your patch up. You should also explain in detail why this patch is needed in the kernel. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: omap-sham - fix several reference count leaks due to pm_runtime_get_sync
On Mon, Nov 23, 2020 at 09:41:15PM +0800, Wang Xiaojun wrote: > On calling pm_runtime_get_sync() the reference count of the device > is incremented. In case of failure, should decrement the reference > count before returning the error. So we fixed it by replacing it > with pm_runtime_resume_and_get. > > Signed-off-by: Wang Xiaojun > --- > drivers/crypto/omap-sham.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) This function doesn't exist in the current cryptodev tree. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 0/5] crypto: caam - avoid allocating memory at crypto request runtime
On Thu, Dec 03, 2020 at 09:34:08AM +0100, Ard Biesheuvel wrote: > > > CRYPTO_ALG_ALLOCATES_MEMORY flag is limited only to > > dm-crypt use-cases, which seems to be 4 entries maximum. > > Therefore in reqsize we allocate memory for maximum 4 entries > > for src and 4 for dst, aligned. > > If the driver needs more than the 4 entries maximum, the memory > > is dynamically allocated, at runtime. > > I'm confused. So the driver does allocate memory in some cases, right? > So why is it justified to remove CRYPTO_ALG_ALLOCATES_MEMORY? Because it's only required by dm-crypt, we should modify the semantics for ALLOCATES_MEMORY such that it only includes those that require allocations even when the SG list is of 4 entries or less. We should update the documentation. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] random: Don't freeze in add_hwgenerator_randomness() if stopping kthread
On Wed, Dec 02, 2020 at 04:28:07PM +0200, Horia Geantă wrote: > > I wasn't able to find a follow-up on this topic. > Could you advise on what's the proper thing to do going forward? I think someone needs to come up with a patch that does not cause regressions. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v2] crypto: aesni - add ccm(aes) algorithm implementation
On Wed, Dec 02, 2020 at 12:41:36AM +0100, Ard Biesheuvel wrote: > > You just explained that TX typically runs in process context, whereas > RX is handled in softirq context. So how exactly are these going to > end up on the same core? When you receive a TCP packet via RX, this should wake up your user- space thread on the same CPU as otherwise you'll pay extra cost on pulling the data into memory again. > Yes, but IPsec will not use the synchronous interface. That doesn't matter when the underlying wireless code is using the sync interface. An async user is completely capable of making the aesni code-path unavailable to the sync user. > Fair enough. But it is unfortunate that we cannot support Ben's use > case without a lot of additional work that serves no purpose > otherwise. To the contrary, I think to fully support Ben's use case you must use the async code path. Otherwise sure you'll see good numbers when you do simple benchmarks like netperf, but when you really load up the system it just falls apart. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v2] crypto: aesni - add ccm(aes) algorithm implementation
On Wed, Dec 02, 2020 at 12:24:47AM +0100, Ard Biesheuvel wrote: > > True. But the fallback only gets executed if the scheduler is stupid > enough to schedule the TX task onto the core that is overloaded doing > RX softirqs. So in the general case, both TX and RX will be using > AES-NI instructions (unless the CCMP is done in hardware which is the > most common case by far) I don't think this makes sense. TX is typically done in response to RX so the natural alignment is for it to be on the same CPU. > Wireless is very different. Wifi uses a medium that is fundamentally > shared, and so the load it can induce is bounded. There is no way a > wifi interface is going to saturate a 64-bit AES-NI core doing CCMP in > software. This sounds pretty tenuous. In any case, even if wireless itself doesn't get you, there could be loads running on top of it, for example, IPsec. > Given the above, can't we be pragmatic here? This code addresses a > niche use case, which is not affected by the general concerns > regarding async crypto. We already have a framework for acceleration that works properly in aesni, I don't want to see us introduce another broken model within the same driver. So either just leave the whole thing along or do it properly by making wireless async. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v2] crypto: aesni - add ccm(aes) algorithm implementation
On Tue, Dec 01, 2020 at 11:27:52PM +0100, Ard Biesheuvel wrote: > > > The problem is that the degradation would come at the worst time, > > when the system is loaded. IOW when you get an interrupt during > > your TX path and get RX traffic that's when you'll take the fallback > > path. > > I can see how in the general case, this is something you would prefer > to avoid. However, on SMP x86_64 systems that implement AES-NI (which > runs at ~1 cycle per byte), I don't see this as a real problem for > this driver. AES-NI is 1 cycle per byte but the fallback is not. > What we could do is expose both versions, where the async version has > a slightly higher priority, so that all users that do support the > async interface will get it, and the wifi stack can use the sync > interface instead. No we've already tried this with IPsec and it doesn't work. That's why the async path exists in aesni. Wireless is no different to IPsec in this respect. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v2] crypto: aesni - add ccm(aes) algorithm implementation
On Tue, Dec 01, 2020 at 11:12:32PM +0100, Ard Biesheuvel wrote: > > What do you mean by just one direction? Ben just confirmed a The TX direction generally executes in process context, which would benefit from an accelerated sync implementation. The RX side on the other hand is always in softirq context. > substantial speedup for his use case, which requires the use of > software encryption even on hardware that could support doing it in > hardware, and that software encryption currently only supports the > synchronous interface. The problem is that the degradation would come at the worst time, when the system is loaded. IOW when you get an interrupt during your TX path and get RX traffic that's when you'll take the fallback path. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v2] crypto: aesni - add ccm(aes) algorithm implementation
On Tue, Dec 01, 2020 at 11:01:57PM +0100, Ard Biesheuvel wrote: > > This is not the first time this has come up. The point is that CCMP in > the wireless stack is not used in 99% of the cases, given that any > wifi hardware built in the last ~10 years can do it in hardware. Only > in exceptional cases, such as Ben's, is there a need for exercising > this interface. Either it matters or it doesn't. If it doesn't matter why are we having this dicussion at all? If it does then fixing just one direction makes no sense. > Also, care to explain why we have synchronous AEADs in the first place > if they are not supposed to be used? Sync AEADs would make sense if you were dealing with a very small amount of data, e.g., one block. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v2] crypto: aesni - add ccm(aes) algorithm implementation
On Tue, Dec 01, 2020 at 02:00:42PM -0800, Ben Greear wrote: > > No one wanted to do this for the last 6+ years, so I don't think it is likely > to happen any time soon. If the patch is better than > existing behaviour, please let it into the kernel. And it is certainly > better in my test case. No I'm not taking this. This just papers over the problem with a bandaid and goes against every other implementation in aesni. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v2] crypto: aesni - add ccm(aes) algorithm implementation
On Tue, Dec 01, 2020 at 08:45:56PM +0100, Ard Biesheuvel wrote: > Add ccm(aes) implementation from linux-wireless mailing list (see > http://permalink.gmane.org/gmane.linux.kernel.wireless.general/126679). > > This eliminates FPU context store/restore overhead existing in more > general ccm_base(ctr(aes-aesni),aes-aesni) case in MAC calculation. > > Suggested-by: Ben Greear > Co-developed-by: Steve deRosier > Signed-off-by: Steve deRosier > Signed-off-by: Ard Biesheuvel > --- > v2: avoid the SIMD helper, as it produces an CRYPTO_ALG_ASYNC aead, which > is not usable by the 802.11 ccmp driver Sorry, but this is not the way to go. Please fix wireless to use the async interface instead. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [RFC][PATCH 00/18] crypto: Add generic Kerberos library
On Tue, Dec 01, 2020 at 09:12:38AM +, David Howells wrote: > > That depends on whether the caller has passed it elsewhere for some other > parallel purpose, but I think I'm going to have to go down that road and > restore it afterwards. Sure but even if you added it to the API the underlying implementataions would just have to do the same thing. Since this is particular to your use-case it's better to leave the complexity where it's needed rather than propagting it to all the crypto drivers. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [RFC][PATCH 00/18] crypto: Add generic Kerberos library
On Tue, Dec 01, 2020 at 08:44:33AM +, David Howells wrote: > Btw, would it be feasible to make it so that an extra parameter can be added > to the cipher buffer-supplying functions, e.g.: > > skcipher_request_set_crypt(req, input, ciphertext_sg, esize, iv); > > such that we can pass in an offset into the output sg as well? Couldn't you just change the output sg to include the offset? Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: ecrdsa - use subsys_initcall instead of module_init
On Mon, Nov 30, 2020 at 10:21:56AM +0800, Tianjia Zhang wrote: > > > That is true only if there are non-generic implementations of > > the algorithms, which is not the case here. Please explain the > > real reason why this is needed. > > This is a generic algorithm, the author Vitaly Chikunov has also confirmed > it, please consider this patch again. As I said, the generic algorithm only needs to be loaded early *if* there are non-generic implementations. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v3] crypto: ccree - rework cache parameters handling
On Sun, Nov 22, 2020 at 09:51:53AM +0200, Gilad Ben-Yossef wrote: > Rework the setting of DMA cache parameters, program more appropriate > values and explicitly set sharability domain. > > Signed-off-by: Gilad Ben-Yossef > --- > > Changes from previous versions: > - After discussion with Rob H., drop notion of setting the parameters > from device tree and just use good defaults for cached/non cached. > > drivers/crypto/ccree/cc_driver.c | 75 +--- > drivers/crypto/ccree/cc_driver.h | 6 +-- > drivers/crypto/ccree/cc_pm.c | 2 +- > 3 files changed, 63 insertions(+), 20 deletions(-) Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: cavium - Use dma_set_mask_and_coherent to simplify code
On Sat, Nov 21, 2020 at 08:56:47AM +0100, Christophe JAILLET wrote: > 'pci_set_dma_mask()' + 'pci_set_consistent_dma_mask()' can be replaced by > an equivalent 'dma_set_mask_and_coherent()' which is much less verbose. > > Signed-off-by: Christophe JAILLET > --- > drivers/crypto/cavium/cpt/cptpf_main.c | 10 ++ > drivers/crypto/cavium/cpt/cptvf_main.c | 10 ++ > 2 files changed, 4 insertions(+), 16 deletions(-) Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: marvell/octeontx - Use dma_set_mask_and_coherent to simplify code
On Sat, Nov 21, 2020 at 08:49:16AM +0100, Christophe JAILLET wrote: > 'pci_set_dma_mask()' + 'pci_set_consistent_dma_mask()' can be replaced by > an equivalent 'dma_set_mask_and_coherent()' which is much less verbose. > > Signed-off-by: Christophe JAILLET > --- > drivers/crypto/marvell/octeontx/otx_cptpf_main.c | 10 ++ > drivers/crypto/marvell/octeontx/otx_cptvf_main.c | 10 ++ > 2 files changed, 4 insertions(+), 16 deletions(-) Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: cavium/zip - Use dma_set_mask_and_coherent to simplify code
On Sat, Nov 21, 2020 at 08:31:31AM +0100, Christophe JAILLET wrote: > 'pci_set_dma_mask()' + 'pci_set_consistent_dma_mask()' can be replaced by > an equivalent 'dma_set_mask_and_coherent()' which is much less verbose. > > Signed-off-by: Christophe JAILLET > --- > drivers/crypto/cavium/zip/zip_main.c | 10 ++ > 1 file changed, 2 insertions(+), 8 deletions(-) Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 075/141] crypto: ccree - Fix fall-through warnings for Clang
On Fri, Nov 20, 2020 at 12:34:56PM -0600, Gustavo A. R. Silva wrote: > In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple > warnings by explicitly adding multiple break statements instead of > letting the code fall through to the next case. > > Link: https://github.com/KSPP/linux/issues/115 > Signed-off-by: Gustavo A. R. Silva > --- > drivers/crypto/ccree/cc_cipher.c | 3 +++ > 1 file changed, 3 insertions(+) Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 0/4] crypto: hisilicon/trng - add HiSilicon TRNG driver support
On Fri, Nov 20, 2020 at 04:56:59PM +0800, Weili Qian wrote: > 1. Move HiSilicon TRNG driver form 'drivers/char/hw_random/' >to 'drivers/crypto/hisilicon/'. > 2. Add support for PRNG in Crypto subsystem. > > Weili Qian (4): > hwrng: hisi - remove HiSilicon TRNG driver > crypto: hisilicon/trng - add HiSilicon TRNG driver support > crypto: hisilicon/trng - add support for PRNG > MAINTAINERS: Move HiSilicon TRNG V2 driver > > MAINTAINERS| 2 +- > arch/arm64/configs/defconfig | 1 + > drivers/char/hw_random/Kconfig | 13 -- > drivers/char/hw_random/Makefile| 1 - > drivers/char/hw_random/hisi-trng-v2.c | 99 -- > drivers/crypto/hisilicon/Kconfig | 8 + > drivers/crypto/hisilicon/Makefile | 1 + > drivers/crypto/hisilicon/trng/Makefile | 2 + > drivers/crypto/hisilicon/trng/trng.c | 334 > + > 9 files changed, 347 insertions(+), 114 deletions(-) > delete mode 100644 drivers/char/hw_random/hisi-trng-v2.c > create mode 100644 drivers/crypto/hisilicon/trng/Makefile > create mode 100644 drivers/crypto/hisilicon/trng/trng.c All applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v2 0/3] crypto: tcrypt enhancements
On Fri, Nov 20, 2020 at 12:04:30PM +0100, Ard Biesheuvel wrote: > Some tcrypt enhancements that I have been using locally to test and > benchmark crypto algorithms on the command line using KVM: > - allow tcrypt.ko to be builtin and defer its initialization to late_initcall > - add 1420 byte blocks to the list of benchmarked block sizes for AEADs and > skciphers, to get an estimate of the performance in the context of a VPN > > Changes since v1: > - use CONFIG_EXPERT not CONFIG_CRYPTO_MANAGER_EXTRA_TESTS to decide whether > tcrypt.ko may be built in > - add Eric's ack to #1 > > Ard Biesheuvel (3): > crypto: tcrypt - don't initialize at subsys_initcall time > crypto: tcrypt - permit tcrypt.ko to be builtin > crypto: tcrypt - include 1420 byte blocks in aead and skcipher > benchmarks > > crypto/Kconfig | 2 +- > crypto/tcrypt.c | 83 +++- > 2 files changed, 46 insertions(+), 39 deletions(-) All applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH RESEND] crypto: qat - fix excluded_middle.cocci warnings
On Thu, Nov 19, 2020 at 10:25:19PM +, Giovanni Cabiddu wrote:
>
> Condition !A || A && B is equivalent to !A || B.
>
> Generated by: scripts/coccinelle/misc/excluded_middle.cocci
>
> Fixes: b76f0ea01312 ("coccinelle: misc: add excluded_middle.cocci script")
> CC: Denis Efremov
> Reported-by: kernel test robot
> Signed-off-by: kernel test robot
> Signed-off-by: Julia Lawall
> Signed-off-by: Giovanni Cabiddu
> ---
> drivers/crypto/qat/qat_common/adf_dev_mgr.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v3 0/4] crypto: aegis128 enhancements
On Tue, Nov 17, 2020 at 02:32:10PM +0100, Ard Biesheuvel wrote: > This series supersedes [0] '[PATCH] crypto: aegis128/neon - optimize tail > block handling', which is included as patch #3 here, but hasn't been > modified substantially. > > Patch #1 should probably go to -stable, even though aegis128 does not appear > to be widely used. > > Patches #2 and #3 improve the SIMD code paths. > > Patch #4 enables fuzz testing for the SIMD code by registering the generic > code as a separate driver if the SIMD code path is enabled. > > Changes since v2: > - add Ondrej's ack to #1 > - fix an issue spotted by Ondrej in #4 where the generic code path would still > use some of the SIMD helpers > > Cc: Ondrej Mosnacek > Cc: Eric Biggers > > [0] > https://lore.kernel.org/linux-crypto/20201107195516.13952-1-a...@kernel.org/ > > Ard Biesheuvel (4): > crypto: aegis128 - wipe plaintext and tag if decryption fails > crypto: aegis128/neon - optimize tail block handling > crypto: aegis128/neon - move final tag check to SIMD domain > crypto: aegis128 - expose SIMD code path as separate driver > > crypto/aegis128-core.c | 245 ++-- > crypto/aegis128-neon-inner.c | 122 -- > crypto/aegis128-neon.c | 21 +- > 3 files changed, 287 insertions(+), 101 deletions(-) All applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [Patch v2 0/6] Enable Qualcomm Crypto Engine on sdm845
On Thu, Nov 19, 2020 at 10:52:27AM -0500, Thara Gopinath wrote: > Qualcomm crypto engine supports hardware accelerated algorithms for > encryption and authentication. Enable support for aes,des,3des encryption > algorithms and sha1,sha256, hmac(sha1),hmac(sha256) authentication > algorithms on sdm845.The patch series has been tested using the kernel > crypto testing module tcrypto.ko. > > v1->v2: > - Rebased to linux-next v5.10-rc4. > - Fixed subject line format in all patches as per Bjorn's feedback. > > Thara Gopinath (6): > dt-binding:clock: Add entry for crypto engine RPMH clock resource > clk:qcom:rpmh: Add CE clock on sdm845. > drivers:crypto:qce: Enable support for crypto engine on sdm845. > drivers:crypto:qce: Fix SHA result buffer corruption issues. > dts:qcom:sdm845: Add dt entries to support crypto engine. > devicetree:bindings:crypto: Extend qcom-qce binding to add support for > crypto engine version 5.4 > > .../devicetree/bindings/crypto/qcom-qce.txt | 4 ++- > arch/arm64/boot/dts/qcom/sdm845.dtsi | 30 +++ > drivers/clk/qcom/clk-rpmh.c | 2 ++ > drivers/crypto/qce/core.c | 17 ++- > drivers/crypto/qce/sha.c | 2 +- > include/dt-bindings/clock/qcom,rpmh.h | 1 + > 6 files changed, 53 insertions(+), 3 deletions(-) Patches 3-4 applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
[PATCH] crypto: cpt - Fix sparse warnings in cptpf
This patch fixes a few sparse warnings that were missed in the
last round.
Signed-off-by: Herbert Xu
diff --git a/drivers/crypto/cavium/cpt/cptpf_main.c
b/drivers/crypto/cavium/cpt/cptpf_main.c
index 24d63bdc5dd2..711b1acdd4e0 100644
--- a/drivers/crypto/cavium/cpt/cptpf_main.c
+++ b/drivers/crypto/cavium/cpt/cptpf_main.c
@@ -244,7 +244,7 @@ static int do_cpt_init(struct cpt_device *cpt, struct
microcode *mcode)
struct ucode_header {
u8 version[CPT_UCODE_VERSION_SZ];
- u32 code_length;
+ __be32 code_length;
u32 data_length;
u64 sram_address;
};
@@ -288,10 +288,10 @@ static int cpt_ucode_load_fw(struct cpt_device *cpt,
const u8 *fw, bool is_ae)
/* Byte swap 64-bit */
for (j = 0; j < (mcode->code_size / 8); j++)
- ((u64 *)mcode->code)[j] = cpu_to_be64(((u64 *)mcode->code)[j]);
+ ((__be64 *)mcode->code)[j] = cpu_to_be64(((u64
*)mcode->code)[j]);
/* MC needs 16-bit swap */
for (j = 0; j < (mcode->code_size / 2); j++)
- ((u16 *)mcode->code)[j] = cpu_to_be16(((u16 *)mcode->code)[j]);
+ ((__be16 *)mcode->code)[j] = cpu_to_be16(((u16
*)mcode->code)[j]);
dev_dbg(dev, "mcode->code_size = %u\n", mcode->code_size);
dev_dbg(dev, "mcode->is_ae = %u\n", mcode->is_ae);
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v3 6/7] crypto: sun4i-ss: enabled stats via debugfs
On Mon, Nov 16, 2020 at 01:53:44PM +, Corentin Labbe wrote:
>
> +#ifdef CONFIG_CRYPTO_DEV_SUN4I_SS_DEBUG
> + /* Ignore error of debugfs */
> + ss->dbgfs_dir = debugfs_create_dir("sun4i-ss", NULL);
> + ss->dbgfs_stats = debugfs_create_file("stats", 0444, ss->dbgfs_dir, ss,
> + &sun4i_ss_debugfs_fops);
> +#endif
Since you didn't use ifdefs in the struct, there is no need to
use ifdefs here either.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: ks-sa-rng.c:undefined reference to `devm_platform_ioremap_resource'
On Fri, Nov 13, 2020 at 11:02:13PM +0800, kernel test robot wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> master
> head: 585e5b17b92dead8a3aca4e3c9876fbca5f7e0ba
> commit: 90c4b29eb1e555fee66f8329a18cb8a070090ad6 hwrng: ks-sa - Enable
> COMPILE_TEST
> date: 12 months ago
> config: s390-randconfig-r022-20201113 (attached as .config)
> compiler: s390-linux-gcc (GCC) 9.3.0
> reproduce (this is a W=1 build):
> wget
> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> #
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=90c4b29eb1e555fee66f8329a18cb8a070090ad6
> git remote add linus
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> git fetch --no-tags linus master
> git checkout 90c4b29eb1e555fee66f8329a18cb8a070090ad6
> # save the attached .config to linux build tree
> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
> ARCH=s390
>
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot
>
> All errors (new ones prefixed by >>):
>s390-linux-ld: drivers/char/hw_random/ks-sa-rng.o: in function
> `ks_sa_rng_probe':
> >> ks-sa-rng.c:(.text+0x2fa): undefined reference to
> >> `devm_platform_ioremap_resource'
---8<---
This patch adds a dependency for KEYSTONE on HAS_IOMEM and OF to
prevent COMPILE_TEST build failures.
Reported-by: kernel test robot
Signed-off-by: Herbert Xu
diff --git a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig
index ab33a2e17cdf..9ff4fb3236f7 100644
--- a/drivers/char/hw_random/Kconfig
+++ b/drivers/char/hw_random/Kconfig
@@ -508,6 +508,7 @@ config HW_RANDOM_NPCM
config HW_RANDOM_KEYSTONE
depends on ARCH_KEYSTONE || COMPILE_TEST
+ depends on HAS_IOMEM && OF
default HW_RANDOM
tristate "TI Keystone NETCP SA Hardware random number generator"
help
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
[PATCH] hwrng: ks-sa - Add dependency on IOMEM and OF
Resent with fixed Subject line.
---8<---
This patch adds a dependency for KEYSTONE on HAS_IOMEM and OF to
prevent COMPILE_TEST build failures.
Reported-by: kernel test robot
Signed-off-by: Herbert Xu
diff --git a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig
index ab33a2e17cdf..9ff4fb3236f7 100644
--- a/drivers/char/hw_random/Kconfig
+++ b/drivers/char/hw_random/Kconfig
@@ -508,6 +508,7 @@ config HW_RANDOM_NPCM
config HW_RANDOM_KEYSTONE
depends on ARCH_KEYSTONE || COMPILE_TEST
+ depends on HAS_IOMEM && OF
default HW_RANDOM
tristate "TI Keystone NETCP SA Hardware random number generator"
help
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
[v2 PATCH] crypto: lib/blake2s - Move selftest prototype into header file
v2
Actually include the header file.
---8<---
This patch fixes a missing prototype warning on blake2s_selftest.
Reported-by: kernel test robot
Signed-off-by: Herbert Xu
diff --git a/include/crypto/internal/blake2s.h
b/include/crypto/internal/blake2s.h
index 74ff77032e52..6e376ae6b6b5 100644
--- a/include/crypto/internal/blake2s.h
+++ b/include/crypto/internal/blake2s.h
@@ -16,6 +16,8 @@ void blake2s_compress_generic(struct blake2s_state
*state,const u8 *block,
void blake2s_compress_arch(struct blake2s_state *state,const u8 *block,
size_t nblocks, const u32 inc);
+bool blake2s_selftest(void);
+
static inline void blake2s_set_lastblock(struct blake2s_state *state)
{
state->f[0] = -1;
diff --git a/lib/crypto/blake2s-selftest.c b/lib/crypto/blake2s-selftest.c
index 79ef404a990d..5d9ea53be973 100644
--- a/lib/crypto/blake2s-selftest.c
+++ b/lib/crypto/blake2s-selftest.c
@@ -3,7 +3,7 @@
* Copyright (C) 2015-2019 Jason A. Donenfeld . All Rights
Reserved.
*/
-#include
+#include
#include
/*
diff --git a/lib/crypto/blake2s.c b/lib/crypto/blake2s.c
index 41025a30c524..6a4b6b78d630 100644
--- a/lib/crypto/blake2s.c
+++ b/lib/crypto/blake2s.c
@@ -17,8 +17,6 @@
#include
#include
-bool blake2s_selftest(void);
-
void blake2s_update(struct blake2s_state *state, const u8 *in, size_t inlen)
{
const size_t fill = BLAKE2S_BLOCK_SIZE - state->buflen;
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
[PATCH] crypto: lib/blake2s - Move selftest prototype into header file
On Fri, Nov 13, 2020 at 04:02:28PM +0800, kernel test robot wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> master
> head: 585e5b17b92dead8a3aca4e3c9876fbca5f7e0ba
> commit: 66d7fb94e4ffe5acc589e0b2b4710aecc1f07a28 crypto: blake2s - generic C
> library implementation and selftest
> date: 12 months ago
> config: parisc-randconfig-r003-20201113 (attached as .config)
> compiler: hppa-linux-gcc (GCC) 9.3.0
> reproduce (this is a W=1 build):
> wget
> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> #
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=66d7fb94e4ffe5acc589e0b2b4710aecc1f07a28
> git remote add linus
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> git fetch --no-tags linus master
> git checkout 66d7fb94e4ffe5acc589e0b2b4710aecc1f07a28
> # save the attached .config to linux build tree
> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
> ARCH=parisc
>
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot
>
> All warnings (new ones prefixed by >>):
>
> >> lib/crypto/blake2s-selftest.c:566:13: warning: no previous prototype for
> >> 'blake2s_selftest' [-Wmissing-prototypes]
> 566 | bool __init blake2s_selftest(void)
> | ^~~~
>
> vim +/blake2s_selftest +566 lib/crypto/blake2s-selftest.c
>
>565
> > 566bool __init blake2s_selftest(void)
---8<---
This patch fixes a missing prototype warning on blake2s_selftest.
Reported-by: kernel test robot
Signed-off-by: Herbert Xu
diff --git a/include/crypto/internal/blake2s.h
b/include/crypto/internal/blake2s.h
index 74ff77032e52..6e376ae6b6b5 100644
--- a/include/crypto/internal/blake2s.h
+++ b/include/crypto/internal/blake2s.h
@@ -16,6 +16,8 @@ void blake2s_compress_generic(struct blake2s_state
*state,const u8 *block,
void blake2s_compress_arch(struct blake2s_state *state,const u8 *block,
size_t nblocks, const u32 inc);
+bool blake2s_selftest(void);
+
static inline void blake2s_set_lastblock(struct blake2s_state *state)
{
state->f[0] = -1;
diff --git a/lib/crypto/blake2s.c b/lib/crypto/blake2s.c
index 41025a30c524..6a4b6b78d630 100644
--- a/lib/crypto/blake2s.c
+++ b/lib/crypto/blake2s.c
@@ -17,8 +17,6 @@
#include
#include
-bool blake2s_selftest(void);
-
void blake2s_update(struct blake2s_state *state, const u8 *in, size_t inlen)
{
const size_t fill = BLAKE2S_BLOCK_SIZE - state->buflen;
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [RFC][PATCH 00/18] crypto: Add generic Kerberos library
On Thu, Nov 26, 2020 at 08:19:41AM +, David Howells wrote: > > I haven't done that yet. Sorry, I should've been more explicit with what I > was after. I was wanting to find out if the nfs/nfsd people are okay with > this (and if there are any gotchas I should know about - it turns out, if I > understand it correctly, the relevant code may being being rewritten a bit > anyway). > > And from you, I was wanting to find out if you're okay with an interface of > this kind in crypto/ where the code is just used directly - or whether I'll > be required to wrap it up in the autoloading, module-handling mechanisms. I don't have any problems with it living under crypto. However, I'd like to see what the sunrpc code looks like before going one way or another. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [RFC][PATCH 00/18] crypto: Add generic Kerberos library
On Thu, Nov 12, 2020 at 12:57:45PM +, David Howells wrote: > > Hi Herbert, Bruce, > > Here's my first cut at a generic Kerberos crypto library in the kernel so > that I can share code between rxrpc and sunrpc (and cifs?). Hi David: I can't find the bit where you are actually sharing this code with sunrpc, am I missing something? Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 2/3] crypto: tcrypt - permit tcrypt.ko to be builtin
On Fri, Nov 20, 2020 at 11:43:40AM +0100, Ard Biesheuvel wrote: > > That would be an option, but since we basically already have our own > local 'EXPERT' option when it comes to crypto testing, I thought I'd > use that instead. Well that creates a loop and changing the select into a dependency may confuse non-expert users who actually want to use this. So I think using EXPERT is the way to go. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 2/3] crypto: tcrypt - permit tcrypt.ko to be builtin
On Fri, Nov 20, 2020 at 11:40:24AM +0100, Ard Biesheuvel wrote: > > Yeah, that would work, but enabling it as a builtin produces a lot of > bogus output if you fail to set the tcrypt.mode=xxx kernel command > line option, so it is really only intended for deliberate use. Perhaps replace it with a depends on m || EXPERT? Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 2/3] crypto: tcrypt - permit tcrypt.ko to be builtin
On Fri, Nov 20, 2020 at 11:34:14AM +0100, Ard Biesheuvel wrote: > On Fri, 20 Nov 2020 at 11:09, Herbert Xu wrote: > > > > On Fri, Nov 20, 2020 at 10:24:44AM +0100, Ard Biesheuvel wrote: > > > > > > OK, I'll apply this on top > > > > > > diff --git a/crypto/Kconfig b/crypto/Kconfig > > > index 9ff2d687e334..959ee48f66a8 100644 > > > --- a/crypto/Kconfig > > > +++ b/crypto/Kconfig > > > @@ -202,7 +202,7 @@ config CRYPTO_AUTHENC > > > config CRYPTO_TEST > > > tristate "Testing module" > > > depends on m || CRYPTO_MANAGER_EXTRA_TESTS > > > - select CRYPTO_MANAGER > > > + depends on CRYPTO_MANAGER > > > > How about just removing the depends line altogether? > > That may break the build, and therefore randconfig build testing: > > crypto/tcrypt.o: In function `do_mult_aead_op': > tcrypt.c:(.text+0x180): undefined reference to `crypto_aead_encrypt' > tcrypt.c:(.text+0x194): undefined reference to `crypto_aead_decrypt' Did you keep the select CRYPTO_MANAGER? That should bring in everything that's needed. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 2/3] crypto: tcrypt - permit tcrypt.ko to be builtin
On Fri, Nov 20, 2020 at 10:24:44AM +0100, Ard Biesheuvel wrote: > > OK, I'll apply this on top > > diff --git a/crypto/Kconfig b/crypto/Kconfig > index 9ff2d687e334..959ee48f66a8 100644 > --- a/crypto/Kconfig > +++ b/crypto/Kconfig > @@ -202,7 +202,7 @@ config CRYPTO_AUTHENC > config CRYPTO_TEST > tristate "Testing module" > depends on m || CRYPTO_MANAGER_EXTRA_TESTS > - select CRYPTO_MANAGER > + depends on CRYPTO_MANAGER How about just removing the depends line altogether? Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: allwinner: sun8i-ce: fix two error path's memory leak
On Sun, Nov 15, 2020 at 07:08:07PM +, Corentin Labbe wrote:
> This patch fixes the following smatch warnings:
> drivers/crypto/allwinner/sun8i-ce/sun8i-ce-hash.c:412
> sun8i_ce_hash_run() warn: possible memory leak of 'result'
> Note: "buf" is leaked as well.
>
> Furthermore, in case of ENOMEM, crypto_finalize_hash_request() was not
> called which was an error.
>
> Fixes: 56f6d5aee88d ("crypto: sun8i-ce - support hash algorithms")
> Reported-by: kernel test robot
> Reported-by: Dan Carpenter
> Signed-off-by: Corentin Labbe
> ---
> .../crypto/allwinner/sun8i-ce/sun8i-ce-hash.c | 20 +++
> 1 file changed, 12 insertions(+), 8 deletions(-)
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: fix a couple of spelling mistakes in Kconfig files
On Sat, Nov 14, 2020 at 12:12:27PM +, Colin King wrote: > From: Colin Ian King > > There are a couple of spelling mistakes in two crypto Kconfig files. > Fix these. > > Signed-off-by: Colin Ian King > --- > drivers/crypto/Kconfig | 2 +- > drivers/crypto/allwinner/Kconfig | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 0/3] crypto: qat - add qat_4xxx driver
On Fri, Nov 13, 2020 at 04:46:40PM +, Giovanni Cabiddu wrote: > Add support for QAT 4xxx devices. > > The first patch reworks the logic that loads the firmware images to > allow for for devices that require multiple firmware images to work. > The second patch introduces an hook to program the vector routing table, > which is introduced in QAT 4XXX, to allow to change the vector associated > with the interrupt source. > The third patch implements the QAT 4xxx driver. > > Giovanni Cabiddu (3): > crypto: qat - target fw images to specific AEs > crypto: qat - add hook to initialize vector routing table > crypto: qat - add qat_4xxx driver > > drivers/crypto/qat/Kconfig| 11 + > drivers/crypto/qat/Makefile | 1 + > drivers/crypto/qat/qat_4xxx/Makefile | 4 + > .../crypto/qat/qat_4xxx/adf_4xxx_hw_data.c| 218 > .../crypto/qat/qat_4xxx/adf_4xxx_hw_data.h| 75 > drivers/crypto/qat/qat_4xxx/adf_drv.c | 320 ++ > drivers/crypto/qat/qat_common/Makefile| 1 + > .../crypto/qat/qat_common/adf_accel_devices.h | 5 + > .../crypto/qat/qat_common/adf_accel_engine.c | 58 +++- > .../crypto/qat/qat_common/adf_cfg_common.h| 3 +- > .../crypto/qat/qat_common/adf_gen4_hw_data.c | 101 ++ > .../crypto/qat/qat_common/adf_gen4_hw_data.h | 99 ++ > drivers/crypto/qat/qat_common/adf_isr.c | 3 + > 13 files changed, 893 insertions(+), 6 deletions(-) > create mode 100644 drivers/crypto/qat/qat_4xxx/Makefile > create mode 100644 drivers/crypto/qat/qat_4xxx/adf_4xxx_hw_data.c > create mode 100644 drivers/crypto/qat/qat_4xxx/adf_4xxx_hw_data.h > create mode 100644 drivers/crypto/qat/qat_4xxx/adf_drv.c > create mode 100644 drivers/crypto/qat/qat_common/adf_gen4_hw_data.c > create mode 100644 drivers/crypto/qat/qat_common/adf_gen4_hw_data.h All applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: omap-aes - Fix PM disable depth imbalance in omap_aes_probe
On Fri, Nov 13, 2020 at 09:17:28PM +0800, Zhang Qilong wrote:
> The pm_runtime_enable will increase power disable depth.
> Thus a pairing decrement is needed on the error handling
> path to keep it balanced according to context.
>
> Fixes: f7b2b5dd6a62a ("crypto: omap-aes - add error check for
> pm_runtime_get_sync")
> Signed-off-by: Zhang Qilong
> ---
> drivers/crypto/omap-aes.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: hisilicon/zip - add a work_queue for zip irq
On Fri, Nov 13, 2020 at 05:32:35PM +0800, Yang Shen wrote: > The patch 'irqchip/gic-v3-its: Balance initial LPI affinity across CPUs' > set the IRQ to an uncentain CPU. If an IRQ is bound to the CPU used by the > thread which is sending request, the throughput will be just half. > > So allocate a 'work_queue' and set as 'WQ_UNBOUND' to do the back half work > on some different CPUS. > > Signed-off-by: Yang Shen > Reviewed-by: Zaibo Xu > --- > drivers/crypto/hisilicon/zip/zip_main.c | 26 +++--- > 1 file changed, 23 insertions(+), 3 deletions(-) Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: sha - split sha.h into sha1.h and sha2.h
inside-secure/safexcel_hash.c | 3 +-
> drivers/crypto/ixp4xx_crypto.c| 2 +-
> drivers/crypto/marvell/cesa/hash.c| 3 +-
> .../crypto/marvell/octeontx/otx_cptvf_algs.c | 3 +-
> drivers/crypto/mediatek/mtk-sha.c | 3 +-
> drivers/crypto/mxs-dcp.c | 3 +-
> drivers/crypto/n2_core.c | 3 +-
> drivers/crypto/nx/nx-sha256.c | 2 +-
> drivers/crypto/nx/nx-sha512.c | 2 +-
> drivers/crypto/nx/nx.c| 2 +-
> drivers/crypto/omap-sham.c| 3 +-
> drivers/crypto/padlock-sha.c | 3 +-
> drivers/crypto/picoxcell_crypto.c | 3 +-
> drivers/crypto/qat/qat_common/qat_algs.c | 3 +-
> drivers/crypto/qce/common.c | 3 +-
> drivers/crypto/qce/core.c | 1 -
> drivers/crypto/qce/sha.h | 3 +-
> drivers/crypto/rockchip/rk3288_crypto.h | 3 +-
> drivers/crypto/s5p-sss.c | 3 +-
> drivers/crypto/sa2ul.c| 3 +-
> drivers/crypto/sa2ul.h| 3 +-
> drivers/crypto/sahara.c | 3 +-
> drivers/crypto/stm32/stm32-hash.c | 3 +-
> drivers/crypto/talitos.c | 3 +-
> drivers/crypto/ux500/hash/hash_core.c | 3 +-
> drivers/firmware/efi/embedded-firmware.c | 2 +-
> .../inline_crypto/ch_ipsec/chcr_ipsec.c | 3 +-
> .../chelsio/inline_crypto/chtls/chtls.h | 3 +-
> drivers/nfc/s3fwrn5/firmware.c| 2 +-
> drivers/tee/tee_core.c| 2 +-
> fs/crypto/fname.c | 2 +-
> fs/crypto/hkdf.c | 2 +-
> fs/ubifs/auth.c | 1 -
> fs/verity/fsverity_private.h | 2 +-
> include/crypto/hash_info.h| 3 +-
> include/crypto/sha1.h | 46 +++
> include/crypto/sha1_base.h| 2 +-
> include/crypto/{sha.h => sha2.h} | 41 ++---
> include/crypto/sha256_base.h | 2 +-
> include/crypto/sha512_base.h | 2 +-
> include/linux/ccp.h | 3 +-
> include/linux/filter.h| 2 +-
> include/linux/purgatory.h | 2 +-
> kernel/crash_core.c | 2 +-
> kernel/kexec_core.c | 1 -
> kernel/kexec_file.c | 2 +-
> lib/crypto/sha256.c | 2 +-
> lib/digsig.c | 2 +-
> lib/sha1.c| 2 +-
> net/ipv6/seg6_hmac.c | 1 -
> net/mptcp/crypto.c| 2 +-
> net/mptcp/options.c | 2 +-
> net/mptcp/subflow.c | 2 +-
> security/integrity/integrity.h| 2 +-
> security/keys/encrypted-keys/encrypted.c | 2 +-
> security/keys/trusted-keys/trusted_tpm1.c | 2 +-
> sound/soc/codecs/cros_ec_codec.c | 2 +-
> 120 files changed, 205 insertions(+), 155 deletions(-)
> create mode 100644 include/crypto/sha1.h
> rename include/crypto/{sha.h => sha2.h} (77%)
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: crypto4xx - Replace bitwise OR with logical OR in crypto4xx_build_pd
On Thu, Nov 12, 2020 at 01:07:02PM -0700, Nathan Chancellor wrote:
> Clang warns:
>
> drivers/crypto/amcc/crypto4xx_core.c:921:60: warning: operator '?:' has
> lower precedence than '|'; '|' will be evaluated first
> [-Wbitwise-conditional-parentheses]
> (crypto_tfm_alg_type(req->tfm) == CRYPTO_ALG_TYPE_AEAD) ?
> ~~~ ^
> drivers/crypto/amcc/crypto4xx_core.c:921:60: note: place parentheses
> around the '|' expression to silence this warning
> (crypto_tfm_alg_type(req->tfm) == CRYPTO_ALG_TYPE_AEAD) ?
> ^
> )
> drivers/crypto/amcc/crypto4xx_core.c:921:60: note: place parentheses
> around the '?:' expression to evaluate it first
> (crypto_tfm_alg_type(req->tfm) == CRYPTO_ALG_TYPE_AEAD) ?
> ^
> (
> 1 warning generated.
>
> It looks like this should have been a logical OR so that
> PD_CTL_HASH_FINAL gets added to the w bitmask if crypto_tfm_alg_type
> is either CRYPTO_ALG_TYPE_AHASH or CRYPTO_ALG_TYPE_AEAD. Change the
> operator so that everything works properly.
>
> Fixes: 4b5b79998af6 ("crypto: crypto4xx - fix stalls under heavy load")
> Link: https://github.com/ClangBuiltLinux/linux/issues/1198
> Signed-off-by: Nathan Chancellor
> ---
> drivers/crypto/amcc/crypto4xx_core.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: crypto: caam/qi - simplify error path for context allocation
On Thu, Nov 12, 2020 at 11:21:46AM +0200, Horia Geantă wrote: > > Wang Qing reports that IS_ERR_OR_NULL() should be matched with > PTR_ERR_OR_ZERO(), not PTR_ERR(). > > As it turns out, the error path always returns an error code, > i.e. NULL is never returned. > Update the code accordingly - s/IS_ERR_OR_NULL/IS_ERR. > > Reported-by: Wang Qing > Signed-off-by: Horia Geantă > --- > drivers/crypto/caam/caamalg_qi.c | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v2] crypto: arm64/gcm - move authentication tag check to SIMD domain
On Tue, Nov 10, 2020 at 10:10:42AM +0100, Ard Biesheuvel wrote: > Instead of copying the calculated authentication tag to memory and > calling crypto_memneq() to verify it, use vector bytewise compare and > min across vector instructions to decide whether the tag is valid. This > is more efficient, and given that the tag is only transiently held in a > NEON register, it is also safer, given that calculated tags for failed > decryptions should be withheld. > > Signed-off-by: Ard Biesheuvel > --- > v2: drop superfluous ')' > > arch/arm64/crypto/ghash-ce-core.S | 15 +++ > arch/arm64/crypto/ghash-ce-glue.c | 46 > 2 files changed, 43 insertions(+), 18 deletions(-) Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto:hisilicon/sec2 - Fix aead authentication setting key error.
On Mon, Nov 09, 2020 at 05:00:27PM +0800, Kai Ye wrote: > Fix aead auth setting key process error. if use soft shash function, driver > need to use digest size replace of the user input key length. > > Signed-off-by: Kai Ye > --- > drivers/crypto/hisilicon/sec2/sec_crypto.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
[PATCH] crypto: sparc - Fix sparse endianness warnings
This patch fixes a coulpe of sparse endianness warnings.
Signed-off-by: Herbert Xu
diff --git a/arch/sparc/crypto/crc32c_glue.c b/arch/sparc/crypto/crc32c_glue.c
index 4e9323229e71..82efb7f81c28 100644
--- a/arch/sparc/crypto/crc32c_glue.c
+++ b/arch/sparc/crypto/crc32c_glue.c
@@ -35,7 +35,7 @@ static int crc32c_sparc64_setkey(struct crypto_shash *hash,
const u8 *key,
if (keylen != sizeof(u32))
return -EINVAL;
- *(__le32 *)mctx = le32_to_cpup((__le32 *)key);
+ *mctx = le32_to_cpup((__le32 *)key);
return 0;
}
diff --git a/arch/sparc/crypto/md5_glue.c b/arch/sparc/crypto/md5_glue.c
index 111283fe837e..511db98d590a 100644
--- a/arch/sparc/crypto/md5_glue.c
+++ b/arch/sparc/crypto/md5_glue.c
@@ -33,10 +33,11 @@ static int md5_sparc64_init(struct shash_desc *desc)
{
struct md5_state *mctx = shash_desc_ctx(desc);
- mctx->hash[0] = cpu_to_le32(MD5_H0);
- mctx->hash[1] = cpu_to_le32(MD5_H1);
- mctx->hash[2] = cpu_to_le32(MD5_H2);
- mctx->hash[3] = cpu_to_le32(MD5_H3);
+ mctx->hash[0] = MD5_H0;
+ mctx->hash[1] = MD5_H1;
+ mctx->hash[2] = MD5_H2;
+ mctx->hash[3] = MD5_H3;
+ le32_to_cpu_array(mctx->hash, 4);
mctx->byte_count = 0;
return 0;
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
[PATCH] crypto: powerpc/sha256-spe - Fix sparse endianness warning
This patch fixes a sparse endianness warning in sha256-spe.
Signed-off-by: Herbert Xu
diff --git a/arch/powerpc/crypto/sha256-spe-glue.c
b/arch/powerpc/crypto/sha256-spe-glue.c
index 88530ae0791f..a6e650a97d8f 100644
--- a/arch/powerpc/crypto/sha256-spe-glue.c
+++ b/arch/powerpc/crypto/sha256-spe-glue.c
@@ -177,7 +177,7 @@ static int ppc_spe_sha256_final(struct shash_desc *desc, u8
*out)
static int ppc_spe_sha224_final(struct shash_desc *desc, u8 *out)
{
- u32 D[SHA256_DIGEST_SIZE >> 2];
+ __be32 D[SHA256_DIGEST_SIZE >> 2];
__be32 *dst = (__be32 *)out;
ppc_spe_sha256_final(desc, (u8 *)D);
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
[PATCH] crypto: mips/octeon - Fix sparse endianness warnings
This patch fixes a number of endianness warnings in the mips/octeon
code.
Signed-off-by: Herbert Xu
diff --git a/arch/mips/cavium-octeon/crypto/octeon-crypto.h
b/arch/mips/cavium-octeon/crypto/octeon-crypto.h
index 7315cc307397..cb68f9e284bb 100644
--- a/arch/mips/cavium-octeon/crypto/octeon-crypto.h
+++ b/arch/mips/cavium-octeon/crypto/octeon-crypto.h
@@ -41,7 +41,7 @@ do { \
*/
#define read_octeon_64bit_hash_dword(index)\
({ \
- u64 __value;\
+ __be64 __value; \
\
__asm__ __volatile__ ( \
"dmfc2 %[rt],0x0048+" STR(index)\
diff --git a/arch/mips/cavium-octeon/crypto/octeon-md5.c
b/arch/mips/cavium-octeon/crypto/octeon-md5.c
index 8c8ea139653e..5ee4ade99b99 100644
--- a/arch/mips/cavium-octeon/crypto/octeon-md5.c
+++ b/arch/mips/cavium-octeon/crypto/octeon-md5.c
@@ -68,10 +68,11 @@ static int octeon_md5_init(struct shash_desc *desc)
{
struct md5_state *mctx = shash_desc_ctx(desc);
- mctx->hash[0] = cpu_to_le32(MD5_H0);
- mctx->hash[1] = cpu_to_le32(MD5_H1);
- mctx->hash[2] = cpu_to_le32(MD5_H2);
- mctx->hash[3] = cpu_to_le32(MD5_H3);
+ mctx->hash[0] = MD5_H0;
+ mctx->hash[1] = MD5_H1;
+ mctx->hash[2] = MD5_H2;
+ mctx->hash[3] = MD5_H3;
+ cpu_to_le32_array(mctx->hash, 4);
mctx->byte_count = 0;
return 0;
@@ -139,8 +140,9 @@ static int octeon_md5_final(struct shash_desc *desc, u8
*out)
}
memset(p, 0, padding);
- mctx->block[14] = cpu_to_le32(mctx->byte_count << 3);
- mctx->block[15] = cpu_to_le32(mctx->byte_count >> 29);
+ mctx->block[14] = mctx->byte_count << 3;
+ mctx->block[15] = mctx->byte_count >> 29;
+ cpu_to_le32_array(mctx->block + 14, 2);
octeon_md5_transform(mctx->block);
octeon_md5_read_hash(mctx);
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 2/3] crypto: tcrypt - permit tcrypt.ko to be builtin
On Mon, Nov 09, 2020 at 09:31:42AM +0100, Ard Biesheuvel wrote: > When working on crypto algorithms, being able to run tcrypt quickly > without booting an entire Linux installation can be very useful. For > instance, QEMU/kvm can be used to boot a kernel from the command line, > and having tcrypt.ko builtin would allow tcrypt to be executed to run > benchmarks, or to run tests for algortithms that need to be instantiated > from templates, without the need to make it past the point where the > rootfs is mounted. > > So let's relax the requirement that tcrypt can only be built as a > module when CRYPTO_MANAGER_EXTRA_TESTS is enabled, as this is already > documented as a crypto development-only symbol. > > Signed-off-by: Ard Biesheuvel > --- > crypto/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/crypto/Kconfig b/crypto/Kconfig > index 094ef56ab7b4..9ff2d687e334 100644 > --- a/crypto/Kconfig > +++ b/crypto/Kconfig > @@ -201,7 +201,7 @@ config CRYPTO_AUTHENC > > config CRYPTO_TEST > tristate "Testing module" > - depends on m > + depends on m || CRYPTO_MANAGER_EXTRA_TESTS > select CRYPTO_MANAGER > help > Quick & dirty crypto test module. This breaks the build: crypto/Kconfig:150:error: recursive dependency detected! crypto/Kconfig:150: symbol CRYPTO_MANAGER_EXTRA_TESTS depends on CRYPTO_MANAGER crypto/Kconfig:119: symbol CRYPTO_MANAGER is selected by CRYPTO_TEST crypto/Kconfig:206: symbol CRYPTO_TEST depends on CRYPTO_MANAGER_EXTRA_TESTS For a resolution refer to Documentation/kbuild/kconfig-language.rst subsection "Kconfig recursive dependency limitations" Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v9,net-next,12/12] crypto: octeontx2: register with linux crypto framework
On Fri, Nov 13, 2020 at 08:44:40AM -0800, Jakub Kicinski wrote: > > SGTM, actually everything starting from patch 4 is in drivers/crypto, > so we can merge the first 3 into net-next and the rest via crypto? Yes of course. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH crypto] crypto: Kconfig - CRYPTO_MANAGER_EXTRA_TESTS requires the manager
On Fri, Nov 13, 2020 at 03:34:36PM +0100, Jason A. Donenfeld wrote: > Thanks. FYI, I intended this for crypto-2.6.git rather than > cryptodev-2.6.git, since it fixes a build failure and is a trivial > fix. Well this has been broken since January so I don't see the urgency in it going in right away. It'll be backported eventually. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
[PATCH] crypto: lib/curve25519 - Move selftest prototype into header file
On Fri, Nov 13, 2020 at 01:56:46PM +0800, kernel test robot wrote:
>
> All warnings (new ones prefixed by >>):
>
> >> lib/crypto/curve25519-selftest.c:1283:13: warning: no previous prototype
> >> for 'curve25519_selftest' [-Wmissing-prototypes]
> 1283 | bool __init curve25519_selftest(void)
> | ^~~
---8<---
This patch moves the curve25519_selftest into curve25519.h so
we don't get a warning from gcc complaining about a missing
prototype.
Reported-by: kernel test robot
Signed-off-by: Herbert Xu
diff --git a/include/crypto/curve25519.h b/include/crypto/curve25519.h
index 4e6dc840b159..ece6a9b5fafc 100644
--- a/include/crypto/curve25519.h
+++ b/include/crypto/curve25519.h
@@ -28,6 +28,8 @@ void curve25519_arch(u8 out[CURVE25519_KEY_SIZE],
void curve25519_base_arch(u8 pub[CURVE25519_KEY_SIZE],
const u8 secret[CURVE25519_KEY_SIZE]);
+bool curve25519_selftest(void);
+
static inline
bool __must_check curve25519(u8 mypublic[CURVE25519_KEY_SIZE],
const u8 secret[CURVE25519_KEY_SIZE],
diff --git a/lib/crypto/curve25519.c b/lib/crypto/curve25519.c
index 288a62cd29b2..fb29739e8c29 100644
--- a/lib/crypto/curve25519.c
+++ b/lib/crypto/curve25519.c
@@ -13,8 +13,6 @@
#include
#include
-bool curve25519_selftest(void);
-
static int __init mod_init(void)
{
if (!IS_ENABLED(CONFIG_CRYPTO_MANAGER_DISABLE_TESTS) &&
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v2] crypto: arm/chacha-neon - optimize for non-block size multiples
On Tue, Nov 03, 2020 at 05:28:09PM +0100, Ard Biesheuvel wrote: > The current NEON based ChaCha implementation for ARM is optimized for > multiples of 4x the ChaCha block size (64 bytes). This makes sense for > block encryption, but given that ChaCha is also often used in the > context of networking, it makes sense to consider arbitrary length > inputs as well. > > For example, WireGuard typically uses 1420 byte packets, and performing > ChaCha encryption involves 5 invocations of chacha_4block_xor_neon() > and 3 invocations of chacha_block_xor_neon(), where the last one also > involves a memcpy() using a buffer on the stack to process the final > chunk of 1420 % 64 == 12 bytes. > > Let's optimize for this case as well, by letting chacha_4block_xor_neon() > deal with any input size between 64 and 256 bytes, using NEON permutation > instructions and overlapping loads and stores. This way, the 140 byte > tail of a 1420 byte input buffer can simply be processed in one go. > > This results in the following performance improvements for 1420 byte > blocks, without significant impact on power-of-2 input sizes. (Note > that Raspberry Pi is widely used in combination with a 32-bit kernel, > even though the core is 64-bit capable) > >Cortex-A8 (BeagleBone) : 7% >Cortex-A15 (Calxeda Midway) : 21% >Cortex-A53 (Raspberry Pi 3) : 3% >Cortex-A72 (Raspberry Pi 4) : 19% > > Cc: Eric Biggers > Cc: "Jason A . Donenfeld" > Signed-off-by: Ard Biesheuvel > --- > v2: > - avoid memcpy() if the residual byte count is exactly 64 bytes > - get rid of register based post increments, and simply rewind the src > pointer as needed (the dst pointer did not need the register post > increment in the first place) > - add benchmark results for 32-bit CPUs to commit log. > > arch/arm/crypto/chacha-glue.c | 34 +++ > arch/arm/crypto/chacha-neon-core.S | 97 ++-- > 2 files changed, 107 insertions(+), 24 deletions(-) Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 00/32] crypto: qat - rework firmware loader in preparation for qat_4xxx
On Fri, Nov 06, 2020 at 07:27:38PM +0800, Jack Xu wrote: > Rework firmware loader in QAT driver in preparation for the support of the > qat_4xxx driver. > > Patch #1 add support for the mof format in the firmware loader > Patches from #2 to #7 introduce some general fixes > Patches from #8 to #30 rework and refactor the firmware loader to support the > new features added by the next generation of QAT devices (QAT GEN4) > Patch #31 introduces the firmware loader changes to support QAT GEN4 devices > > Giovanni Cabiddu (1): > crypto: qat - support for mof format in fw loader > > Jack Xu (31): > crypto: qat - loader: fix status check in qat_hal_put_rel_rd_xfer() > crypto: qat - loader: fix CSR access > crypto: qat - loader: fix error message > crypto: qat - loader: remove unnecessary parenthesis > crypto: qat - loader: introduce additional parenthesis > crypto: qat - loader: rename qat_uclo_del_uof_obj() > crypto: qat - loader: add support for relative FW ucode loading > crypto: qat - loader: change type for ctx_mask > crypto: qat - loader: change micro word data mask > crypto: qat - loader: refactor AE start > crypto: qat - loader: remove global CSRs helpers > crypto: qat - loader: move defines to header files > crypto: qat - loader: refactor qat_uclo_set_ae_mode() > crypto: qat - loader: refactor long expressions > crypto: qat - loader: introduce chip info structure > crypto: qat - loader: replace check based on DID > crypto: qat - loader: add next neighbor to chip_info > crypto: qat - loader: add support for lm2 and lm3 > crypto: qat - loader: add local memory size to chip info > crypto: qat - loader: add reset CSR and mask to chip info > crypto: qat - loader: add clock enable CSR to chip info > crypto: qat - loader: add wake up event to chip info > crypto: qat - loader: add misc control CSR to chip info > crypto: qat - loader: add check for null pointer > crypto: qat - loader: use ae_mask > crypto: qat - loader: add CSS3K support > crypto: qat - loader: add FCU CSRs to chip info > crypto: qat - loader: allow to target specific AEs > crypto: qat - loader: add support for shared ustore > crypto: qat - loader: add support for broadcasting mode > crypto: qat - loader: add gen4 firmware loader > > .../crypto/qat/qat_common/adf_accel_devices.h | 2 + > .../crypto/qat/qat_common/adf_accel_engine.c | 13 +- > .../crypto/qat/qat_common/adf_common_drv.h| 19 +- > .../qat/qat_common/icp_qat_fw_loader_handle.h | 26 +- > drivers/crypto/qat/qat_common/icp_qat_hal.h | 63 +- > drivers/crypto/qat/qat_common/icp_qat_uclo.h | 132 +++- > drivers/crypto/qat/qat_common/qat_hal.c | 400 +++--- > drivers/crypto/qat/qat_common/qat_uclo.c | 737 ++ > 8 files changed, 1097 insertions(+), 295 deletions(-) All applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: arm64/chacha - simplify tail block handling
On Fri, Nov 06, 2020 at 05:39:38PM +0100, Ard Biesheuvel wrote: > Based on lessons learnt from optimizing the 32-bit version of this driver, > we can simplify the arm64 version considerably, by reordering the final > two stores when the last block is not a multiple of 64 bytes. This removes > the need to use permutation instructions to calculate the elements that are > clobbered by the final overlapping store, given that the store of the > penultimate block now follows it, and that one carries the correct values > for those elements already. > > While at it, simplify the overlapping loads as well, by calculating the > address of the final overlapping load upfront, and switching to this > address for every load that would otherwise extend past the end of the > source buffer. > > There is no impact on performance, but the resulting code is substantially > smaller and easier to follow. > > Cc: Eric Biggers > Cc: "Jason A . Donenfeld" > Signed-off-by: Ard Biesheuvel > --- > arch/arm64/crypto/chacha-neon-core.S | 193 +++- > 1 file changed, 69 insertions(+), 124 deletions(-) Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: qat - replace pci with PCI in comments
On Tue, Nov 03, 2020 at 05:29:36PM +, Giovanni Cabiddu wrote: > From: Adam Guerin > > Change all lower case pci in comments to be upper case PCI. > > Suggested-by: Andy Shevchenko > Signed-off-by: Adam Guerin > Reviewed-by: Giovanni Cabiddu > Reviewed-by: Andy Shevchenko > Signed-off-by: Giovanni Cabiddu > --- > drivers/crypto/qat/qat_common/adf_dev_mgr.c | 4 ++-- > drivers/crypto/qat/qat_common/adf_sriov.c | 4 ++-- > 2 files changed, 4 insertions(+), 4 deletions(-) Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH crypto] crypto: Kconfig - CRYPTO_MANAGER_EXTRA_TESTS requires the manager
On Mon, Nov 02, 2020 at 02:48:15PM +0100, Jason A. Donenfeld wrote:
> The extra tests in the manager actually require the manager to be
> selected too. Otherwise the linker gives errors like:
>
> ld: arch/x86/crypto/chacha_glue.o: in function `chacha_simd_stream_xor':
> chacha_glue.c:(.text+0x422): undefined reference to
> `crypto_simd_disabled_for_test'
>
> Fixes: 2343d1529aff ("crypto: Kconfig - allow tests to be disabled when
> manager is disabled")
> Signed-off-by: Jason A. Donenfeld
> ---
> crypto/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: qat - remove cast for mailbox CSR
On Mon, Nov 02, 2020 at 05:04:54PM +, Giovanni Cabiddu wrote: > From: Adam Guerin > > Remove cast for mailbox CSR in adf_admin.c as it is not needed. > > Suggested-by: Andy Shevchenko > Signed-off-by: Adam Guerin > Reviewed-by: Giovanni Cabiddu > Reviewed-by: Andy Shevchenko > Signed-off-by: Giovanni Cabiddu > --- > drivers/crypto/qat/qat_common/adf_admin.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v2 5/5] crypto: hisilicon/hpre - add 'CURVE25519' algorithm
On Mon, Nov 02, 2020 at 10:31:05AM +0800, Meng Yu wrote: > Enable 'CURVE25519' algorithm in 'Kunpeng 930'. > > Signed-off-by: Meng Yu > Reviewed-by: Zaibo Xu > Reported-by: kernel test robot > --- > drivers/crypto/hisilicon/hpre/hpre.h| 2 + > drivers/crypto/hisilicon/hpre/hpre_crypto.c | 387 > +++- > 2 files changed, 381 insertions(+), 8 deletions(-) This is not sparse clean: CC [M] drivers/crypto/hisilicon/sec2/sec_crypto.o ../drivers/crypto/hisilicon/hpre/hpre_crypto.c:2073:18: warning: invalid assignment: |= ../drivers/crypto/hisilicon/hpre/hpre_crypto.c:2073:18:left side has type restricted __le32 ../drivers/crypto/hisilicon/hpre/hpre_crypto.c:2073:18:right side has type unsigned int ../drivers/crypto/hisilicon/hpre/hpre_crypto.c:2192:20: warning: restricted __le32 degrades to integer Please fix and resubmit. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
