linux.git/crypto, branch v5.18 Clone of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git Merge tag 'for-5.18/64bit-pi-2022-03-25' of git://git.kernel.dk/linux-block 2022-03-26T19:01:35+00:00 Linus Torvalds torvalds@linux-foundation.org 2022-03-26T19:01:35+00:00 3f7282139fe1594be464b90141d56738e7a0ea8a Pull block layer 64-bit data integrity support from Jens Axboe: "This adds support for 64-bit data integrity in the block layer and in NVMe" * tag 'for-5.18/64bit-pi-2022-03-25' of git://git.kernel.dk/linux-block: crypto: fix crc64 testmgr digest byte order nvme: add support for enhanced metadata block: add pi for extended integrity crypto: add rocksoft 64b crc guard tag framework lib: add rocksoft model crc64 linux/kernel: introduce lower_48_bits function asm-generic: introduce be48 unaligned accessors nvme: allow integrity on extended metadata formats block: support pi with extended metadata 
Pull block layer 64-bit data integrity support from Jens Axboe:
 "This adds support for 64-bit data integrity in the block layer and in
  NVMe"

* tag 'for-5.18/64bit-pi-2022-03-25' of git://git.kernel.dk/linux-block:
  crypto: fix crc64 testmgr digest byte order
  nvme: add support for enhanced metadata
  block: add pi for extended integrity
  crypto: add rocksoft 64b crc guard tag framework
  lib: add rocksoft model crc64
  linux/kernel: introduce lower_48_bits function
  asm-generic: introduce be48 unaligned accessors
  nvme: allow integrity on extended metadata formats
  block: support pi with extended metadata
crypto: fix crc64 testmgr digest byte order 2022-03-23T01:44:29+00:00 Keith Busch kbusch@kernel.org 2022-03-22T14:21:07+00:00 1e21270685ae4c14361dd501da62cdc4be867d4e The result is set in little endian, so the expected digest needs to be consistent for big endian machines. Fixes: f3813f4b287e ("crypto: add rocksoft 64b crc guard tag framework") Reported-by: Vasily Gorbik <gor@linux.ibm.com> Reported-by: Corentin Labbe <clabbe.montjoie@gmail.com> Signed-off-by: Keith Busch <kbusch@kernel.org> Link: https://lore.kernel.org/r/20220322142107.4581-1-kbusch@kernel.org Signed-off-by: Jens Axboe <axboe@kernel.dk> 
The result is set in little endian, so the expected digest needs to
be consistent for big endian machines.

Fixes: f3813f4b287e ("crypto: add rocksoft 64b crc guard tag framework")
Reported-by: Vasily Gorbik <gor@linux.ibm.com>
Reported-by: Corentin Labbe <clabbe.montjoie@gmail.com>
Signed-off-by: Keith Busch <kbusch@kernel.org>
Link: https://lore.kernel.org/r/20220322142107.4581-1-kbusch@kernel.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Merge branch 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 2022-03-21T23:02:36+00:00 Linus Torvalds torvalds@linux-foundation.org 2022-03-21T23:02:36+00:00 93e220a62da36f766b3188e76e234607e41488f9 Pull crypto updates from Herbert Xu: "API: - hwrng core now credits for low-quality RNG devices. Algorithms: - Optimisations for neon aes on arm/arm64. - Add accelerated crc32_be on arm64. - Add ffdheXYZ(dh) templates. - Disallow hmac keys < 112 bits in FIPS mode. - Add AVX assembly implementation for sm3 on x86. Drivers: - Add missing local_bh_disable calls for crypto_engine callback. - Ensure BH is disabled in crypto_engine callback path. - Fix zero length DMA mappings in ccree. - Add synchronization between mailbox accesses in octeontx2. - Add Xilinx SHA3 driver. - Add support for the TDES IP available on sama7g5 SoC in atmel" * 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: (137 commits) crypto: xilinx - Turn SHA into a tristate and allow COMPILE_TEST MAINTAINERS: update HPRE/SEC2/TRNG driver maintainers list crypto: dh - Remove the unused function dh_safe_prime_dh_alg() hwrng: nomadik - Change clk_disable to clk_disable_unprepare crypto: arm64 - cleanup comments crypto: qat - fix initialization of pfvf rts_map_msg structures crypto: qat - fix initialization of pfvf cap_msg structures crypto: qat - remove unneeded assignment crypto: qat - disable registration of algorithms crypto: hisilicon/qm - fix memset during queues clearing crypto: xilinx: prevent probing on non-xilinx hardware crypto: marvell/octeontx - Use swap() instead of open coding it crypto: ccree - Fix use after free in cc_cipher_exit() crypto: ccp - ccp_dmaengine_unregister release dma channels crypto: octeontx2 - fix missing unlock hwrng: cavium - fix NULL but dereferenced coccicheck error crypto: cavium/nitrox - don't cast parameter in bit operations crypto: vmx - add missing dependencies MAINTAINERS: Add maintainer for Xilinx ZynqMP SHA3 driver crypto: xilinx - Add Xilinx SHA3 driver ... 
Pull crypto updates from Herbert Xu:
 "API:
   - hwrng core now credits for low-quality RNG devices.

  Algorithms:
   - Optimisations for neon aes on arm/arm64.
   - Add accelerated crc32_be on arm64.
   - Add ffdheXYZ(dh) templates.
   - Disallow hmac keys < 112 bits in FIPS mode.
   - Add AVX assembly implementation for sm3 on x86.

  Drivers:
   - Add missing local_bh_disable calls for crypto_engine callback.
   - Ensure BH is disabled in crypto_engine callback path.
   - Fix zero length DMA mappings in ccree.
   - Add synchronization between mailbox accesses in octeontx2.
   - Add Xilinx SHA3 driver.
   - Add support for the TDES IP available on sama7g5 SoC in atmel"

* 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: (137 commits)
  crypto: xilinx - Turn SHA into a tristate and allow COMPILE_TEST
  MAINTAINERS: update HPRE/SEC2/TRNG driver maintainers list
  crypto: dh - Remove the unused function dh_safe_prime_dh_alg()
  hwrng: nomadik - Change clk_disable to clk_disable_unprepare
  crypto: arm64 - cleanup comments
  crypto: qat - fix initialization of pfvf rts_map_msg structures
  crypto: qat - fix initialization of pfvf cap_msg structures
  crypto: qat - remove unneeded assignment
  crypto: qat - disable registration of algorithms
  crypto: hisilicon/qm - fix memset during queues clearing
  crypto: xilinx: prevent probing on non-xilinx hardware
  crypto: marvell/octeontx - Use swap() instead of open coding it
  crypto: ccree - Fix use after free in cc_cipher_exit()
  crypto: ccp - ccp_dmaengine_unregister release dma channels
  crypto: octeontx2 - fix missing unlock
  hwrng: cavium - fix NULL but dereferenced coccicheck error
  crypto: cavium/nitrox - don't cast parameter in bit operations
  crypto: vmx - add missing dependencies
  MAINTAINERS: Add maintainer for Xilinx ZynqMP SHA3 driver
  crypto: xilinx - Add Xilinx SHA3 driver
  ...
crypto: dh - Remove the unused function dh_safe_prime_dh_alg() 2022-03-14T02:45:45+00:00 Jiapeng Chong jiapeng.chong@linux.alibaba.com 2022-03-08T07:55:37+00:00 c6ded03bcac9dde5bc7b4a1121efa050a28118b0 Fix the following W=1 kernel warnings: crypto/dh.c:311:31: warning: unused function 'dh_safe_prime_dh_alg' [-Wunused-function] Reported-by: Abaci Robot <abaci@linux.alibaba.com> Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> 
Fix the following W=1 kernel warnings:

crypto/dh.c:311:31: warning: unused function 'dh_safe_prime_dh_alg'
[-Wunused-function]

Reported-by: Abaci Robot <abaci@linux.alibaba.com>
Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
KEYS: asymmetric: properly validate hash_algo and encoding 2022-03-09T23:47:13+00:00 Eric Biggers ebiggers@google.com 2022-02-08T05:24:48+00:00 590bfb57b2328951d5833979e7ca1d5fde2e609a It is insecure to allow arbitrary hash algorithms and signature encodings to be used with arbitrary signature algorithms. Notably, ECDSA, ECRDSA, and SM2 all sign/verify raw hash values and don't disambiguate between different hash algorithms like RSA PKCS#1 v1.5 padding does. Therefore, they need to be restricted to certain sets of hash algorithms (ideally just one, but in practice small sets are used). Additionally, the encoding is an integral part of modern signature algorithms, and is not supposed to vary. Therefore, tighten the checks of hash_algo and encoding done by software_key_determine_akcipher(). Also rearrange the parameters to software_key_determine_akcipher() to put the public_key first, as this is the most important parameter and it often determines everything else. Fixes: 299f561a6693 ("x509: Add support for parsing x509 certs with ECDSA keys") Fixes: 215525639631 ("X.509: support OSCCA SM2-with-SM3 certificate verification") Fixes: 0d7a78643f69 ("crypto: ecrdsa - add EC-RDSA (GOST 34.10) algorithm") Cc: stable@vger.kernel.org Tested-by: Stefan Berger <stefanb@linux.ibm.com> Tested-by: Tianjia Zhang <tianjia.zhang@linux.alibaba.com> Signed-off-by: Eric Biggers <ebiggers@google.com> Reviewed-by: Vitaly Chikunov <vt@altlinux.org> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org> 
It is insecure to allow arbitrary hash algorithms and signature
encodings to be used with arbitrary signature algorithms.  Notably,
ECDSA, ECRDSA, and SM2 all sign/verify raw hash values and don't
disambiguate between different hash algorithms like RSA PKCS#1 v1.5
padding does.  Therefore, they need to be restricted to certain sets of
hash algorithms (ideally just one, but in practice small sets are used).
Additionally, the encoding is an integral part of modern signature
algorithms, and is not supposed to vary.

Therefore, tighten the checks of hash_algo and encoding done by
software_key_determine_akcipher().

Also rearrange the parameters to software_key_determine_akcipher() to
put the public_key first, as this is the most important parameter and it
often determines everything else.

Fixes: 299f561a6693 ("x509: Add support for parsing x509 certs with ECDSA keys")
Fixes: 215525639631 ("X.509: support OSCCA SM2-with-SM3 certificate verification")
Fixes: 0d7a78643f69 ("crypto: ecrdsa - add EC-RDSA (GOST 34.10) algorithm")
Cc: stable@vger.kernel.org
Tested-by: Stefan Berger <stefanb@linux.ibm.com>
Tested-by: Tianjia Zhang <tianjia.zhang@linux.alibaba.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Vitaly Chikunov <vt@altlinux.org>
Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
KEYS: asymmetric: enforce that sig algo matches key algo 2022-03-09T23:46:59+00:00 Eric Biggers ebiggers@google.com 2022-02-08T05:24:47+00:00 2abc9c246e0548e52985b10440c9ea3e9f65f793 Most callers of public_key_verify_signature(), including most indirect callers via verify_signature() as well as pkcs7_verify_sig_chain(), don't check that public_key_signature::pkey_algo matches public_key::pkey_algo. These should always match. However, a malicious signature could intentionally declare an unintended algorithm. It is essential that such signatures be rejected outright, or that the algorithm of the *key* be used -- not the algorithm of the signature as that would allow attackers to choose the algorithm used. Currently, public_key_verify_signature() correctly uses the key's algorithm when deciding which akcipher to allocate. That's good. However, it uses the signature's algorithm when deciding whether to do the first step of SM2, which is incorrect. Also, v4.19 and older kernels used the signature's algorithm for the entire process. Prevent such errors by making public_key_verify_signature() enforce that the signature's algorithm (if given) matches the key's algorithm. Also remove two checks of this done by callers, which are now redundant. Cc: stable@vger.kernel.org Tested-by: Stefan Berger <stefanb@linux.ibm.com> Tested-by: Tianjia Zhang <tianjia.zhang@linux.alibaba.com> Signed-off-by: Eric Biggers <ebiggers@google.com> Reviewed-by: Vitaly Chikunov <vt@altlinux.org> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org> 
Most callers of public_key_verify_signature(), including most indirect
callers via verify_signature() as well as pkcs7_verify_sig_chain(),
don't check that public_key_signature::pkey_algo matches
public_key::pkey_algo.  These should always match.  However, a malicious
signature could intentionally declare an unintended algorithm.  It is
essential that such signatures be rejected outright, or that the
algorithm of the *key* be used -- not the algorithm of the signature as
that would allow attackers to choose the algorithm used.

Currently, public_key_verify_signature() correctly uses the key's
algorithm when deciding which akcipher to allocate.  That's good.
However, it uses the signature's algorithm when deciding whether to do
the first step of SM2, which is incorrect.  Also, v4.19 and older
kernels used the signature's algorithm for the entire process.

Prevent such errors by making public_key_verify_signature() enforce that
the signature's algorithm (if given) matches the key's algorithm.

Also remove two checks of this done by callers, which are now redundant.

Cc: stable@vger.kernel.org
Tested-by: Stefan Berger <stefanb@linux.ibm.com>
Tested-by: Tianjia Zhang <tianjia.zhang@linux.alibaba.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Vitaly Chikunov <vt@altlinux.org>
Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
KEYS: remove support for asym_tpm keys 2022-03-08T11:55:52+00:00 Eric Biggers ebiggers@google.com 2022-01-28T19:56:55+00:00 d3cff4a95ed78ca192fc4bbb2743d13b7a6cc555 asym_tpm keys are tied to TPM v1.2, which uses outdated crypto and has been deprecated in favor of TPM v2.0 for over 7 years. A very quick look at this code also immediately found some memory safety bugs (https://lore.kernel.org/r/20220113235440.90439-2-ebiggers@kernel.org). Note that this code is reachable by unprivileged users. According to Jarkko (one of the keyrings subsystem maintainers), this code has no practical use cases, and he isn't willing to maintain it (https://lore.kernel.org/r/YfFZPbKkgYJGWu1Q@iki.fi). Therefore, let's remove it. Note that this feature didn't have any documentation or tests, so we don't need to worry about removing those. Cc: David Howells <dhowells@redhat.com> Cc: Denis Kenzior <denkenz@gmail.com> Cc: James Morris <jmorris@namei.org> Cc: Jarkko Sakkinen <jarkko@kernel.org> Cc: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Eric Biggers <ebiggers@google.com> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Acked-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org> 
asym_tpm keys are tied to TPM v1.2, which uses outdated crypto and has
been deprecated in favor of TPM v2.0 for over 7 years.  A very quick
look at this code also immediately found some memory safety bugs
(https://lore.kernel.org/r/20220113235440.90439-2-ebiggers@kernel.org).
Note that this code is reachable by unprivileged users.

According to Jarkko (one of the keyrings subsystem maintainers), this
code has no practical use cases, and he isn't willing to maintain it
(https://lore.kernel.org/r/YfFZPbKkgYJGWu1Q@iki.fi).

Therefore, let's remove it.

Note that this feature didn't have any documentation or tests, so we
don't need to worry about removing those.

Cc: David Howells <dhowells@redhat.com>
Cc: Denis Kenzior <denkenz@gmail.com>
Cc: James Morris <jmorris@namei.org>
Cc: Jarkko Sakkinen <jarkko@kernel.org>
Cc: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
KEYS: x509: remove dead code that set ->unsupported_sig 2022-03-08T08:33:18+00:00 Eric Biggers ebiggers@google.com 2022-01-19T00:54:36+00:00 8bdc3e05cc78513b7495366ef9b962a3ea568e8e The X.509 parser always sets cert->sig->pkey_algo and cert->sig->hash_algo on success, since x509_note_sig_algo() is a mandatory action in the X.509 ASN.1 grammar, and it returns an error if the signature's algorithm is unknown. Thus, remove the dead code which handled these fields being NULL. Acked-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Eric Biggers <ebiggers@google.com> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org> 
The X.509 parser always sets cert->sig->pkey_algo and
cert->sig->hash_algo on success, since x509_note_sig_algo() is a
mandatory action in the X.509 ASN.1 grammar, and it returns an error if
the signature's algorithm is unknown.  Thus, remove the dead code which
handled these fields being NULL.

Acked-by: Jarkko Sakkinen <jarkko@kernel.org>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
KEYS: x509: remove never-set ->unsupported_key flag 2022-03-08T08:33:18+00:00 Eric Biggers ebiggers@google.com 2022-01-19T00:54:35+00:00 9f8b3f321f39d6ff63fb40673c3be61b73ba0a1d The X.509 parser always sets cert->pub->pkey_algo on success, since x509_extract_key_data() is a mandatory action in the X.509 ASN.1 grammar, and it returns an error if the algorithm is unknown. Thus, remove the dead code which handled this field being NULL. This results in the ->unsupported_key flag never being set, so remove that too. Signed-off-by: Eric Biggers <ebiggers@google.com> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org> 
The X.509 parser always sets cert->pub->pkey_algo on success, since
x509_extract_key_data() is a mandatory action in the X.509 ASN.1
grammar, and it returns an error if the algorithm is unknown.  Thus,
remove the dead code which handled this field being NULL.  This results
in the ->unsupported_key flag never being set, so remove that too.

Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
KEYS: x509: remove unused fields 2022-03-08T08:33:18+00:00 Eric Biggers ebiggers@google.com 2022-01-19T00:54:34+00:00 7804fe9e8dc70846ff2c683f4781ed75499b12ae Remove unused fields from struct x509_parse_context. Acked-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Eric Biggers <ebiggers@google.com> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org> 
Remove unused fields from struct x509_parse_context.

Acked-by: Jarkko Sakkinen <jarkko@kernel.org>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>