kernel/linux.git/certs, branch v6.19.11

sign-file,extract-cert: use pkcs11 provider for OPENSSL MAJOR >= 3

2024-09-20T16:52:48+00:00

ENGINE API has been deprecated since OpenSSL version 3.0 [1]. Distros have started dropping support from headers and in future it will likely disappear also from library. It has been superseded by the PROVIDER API, so use it instead for OPENSSL MAJOR >= 3. [1] https://github.com/openssl/openssl/blob/master/README-ENGINES.md [jarkko: fixed up alignment issues reported by checkpatch.pl --strict] Signed-off-by: Jan Stancek Reviewed-by: Jarkko Sakkinen Tested-by: R Nageswara Sastry Reviewed-by: Neal Gompa Signed-off-by: Jarkko Sakkinen

sign-file,extract-cert: avoid using deprecated ERR_get_error_line()

2024-09-20T16:49:52+00:00

ERR_get_error_line() is deprecated since OpenSSL 3.0. Use ERR_peek_error_line() instead, and combine display_openssl_errors() and drain_openssl_errors() to a single function where parameter decides if it should consume errors silently. Signed-off-by: Jan Stancek Reviewed-by: Jarkko Sakkinen Tested-by: R Nageswara Sastry Reviewed-by: Neal Gompa Signed-off-by: Jarkko Sakkinen

sign-file,extract-cert: move common SSL helper functions to a header

2024-09-20T16:49:52+00:00

Couple error handling helpers are repeated in both tools, so move them to a common header. Signed-off-by: Jan Stancek Reviewed-by: Jarkko Sakkinen Tested-by: R Nageswara Sastry Reviewed-by: Neal Gompa Signed-off-by: Jarkko Sakkinen

kbuild: use $(src) instead of $(srctree)/$(src) for source directory

2024-05-09T19:34:52+00:00

Kbuild conventionally uses $(obj)/ for generated files, and $(src)/ for checked-in source files. It is merely a convention without any functional difference. In fact, $(obj) and $(src) are exactly the same, as defined in scripts/Makefile.build: src := $(obj) When the kernel is built in a separate output directory, $(src) does not accurately reflect the source directory location. While Kbuild resolves this discrepancy by specifying VPATH=$(srctree) to search for source files, it does not cover all cases. For example, when adding a header search path for local headers, -I$(srctree)/$(src) is typically passed to the compiler. This introduces inconsistency between upstream and downstream Makefiles because $(src) is used instead of $(srctree)/$(src) for the latter. To address this inconsistency, this commit changes the semantics of $(src) so that it always points to the directory in the source tree. Going forward, the variables used in Makefiles will have the following meanings: $(obj) - directory in the object tree $(src) - directory in the source tree (changed by this commit) $(objtree) - the top of the kernel object tree $(srctree) - the top of the kernel source tree Consequently, $(srctree)/$(src) in upstream Makefiles need to be replaced with $(src). Signed-off-by: Masahiro Yamada Reviewed-by: Nicolas Schier

Merge tag 'v6.7-p1' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6

2023-11-03T02:15:30+00:00

Pull crypto updates from Herbert Xu: "API: - Add virtual-address based lskcipher interface - Optimise ahash/shash performance in light of costly indirect calls - Remove ahash alignmask attribute Algorithms: - Improve AES/XTS performance of 6-way unrolling for ppc - Remove some uses of obsolete algorithms (md4, md5, sha1) - Add FIPS 202 SHA-3 support in pkcs1pad - Add fast path for single-page messages in adiantum - Remove zlib-deflate Drivers: - Add support for S4 in meson RNG driver - Add STM32MP13x support in stm32 - Add hwrng interface support in qcom-rng - Add support for deflate algorithm in hisilicon/zip" * tag 'v6.7-p1' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: (283 commits) crypto: adiantum - flush destination page before unmapping crypto: testmgr - move pkcs1pad(rsa,sha3-*) to correct place Documentation/module-signing.txt: bring up to date module: enable automatic module signing with FIPS 202 SHA-3 crypto: asymmetric_keys - allow FIPS 202 SHA-3 signatures crypto: rsa-pkcs1pad - Add FIPS 202 SHA-3 support crypto: FIPS 202 SHA-3 register in hash info for IMA x509: Add OIDs for FIPS 202 SHA-3 hash and signatures crypto: ahash - optimize performance when wrapping shash crypto: ahash - check for shash type instead of not ahash type crypto: hash - move "ahash wrapping shash" functions to ahash.c crypto: talitos - stop using crypto_ahash::init crypto: chelsio - stop using crypto_ahash::init crypto: ahash - improve file comment crypto: ahash - remove struct ahash_request_priv crypto: ahash - remove crypto_ahash_alignmask crypto: gcm - stop using alignmask of ahash crypto: chacha20poly1305 - stop using alignmask of ahash crypto: ccm - stop using alignmask of ahash net: ipv6: stop checking crypto_ahash_alignmask ...

certs: Only allow certs signed by keys on the builtin keyring

2023-10-31T12:22:36+00:00

Originally the secondary trusted keyring provided a keyring to which extra keys may be added, provided those keys were not blacklisted and were vouched for by a key built into the kernel or already in the secondary trusted keyring. On systems with the machine keyring configured, additional keys may also be vouched for by a key on the machine keyring. Prevent loading additional certificates directly onto the secondary keyring, vouched for by keys on the machine keyring, yet allow these certificates to be loaded onto other trusted keyrings. Reviewed-by: Jarkko Sakkinen Signed-off-by: Mimi Zohar

module: enable automatic module signing with FIPS 202 SHA-3

2023-10-27T10:04:30+00:00

Add Kconfig options to use SHA-3 for kernel module signing. 256 size for RSA only, and higher sizes for RSA and NIST P-384. Signed-off-by: Dimitri John Ledkov Signed-off-by: Herbert Xu

certs: Limit MODULE_SIG_KEY_TYPE_ECDSA to SHA384 or SHA512

2023-10-20T05:39:26+00:00

NIST FIPS 186-5 states that it is recommended that the security strength associated with the bit length of n and the security strength of the hash function be the same, or higher upon agreement. Given NIST P384 curve is used, force using either SHA384 or SHA512. Signed-off-by: Dimitri John Ledkov Signed-off-by: Herbert Xu

certs: Reference revocation list for all keyrings

2023-08-17T20:12:41+00:00

Systems booted with shim have a Forbidden Signature Database called mokx. During boot, hashes and certs contained within the mokx are loaded into the blacklist keyring. When calling verify_pkcs7_message_sig the contents of the blacklist keyring (or revocation list) are referenced when validating keys on the platform keyring. Currently, when validating against the secondary or builtin keyrings, the revocation list is not referenced. Move up the check to allow the revocation list to be used with all keyrings, including the secondary and builtin, allowing the system owner to take corrective action should a vulnerability be found within keys contained within either keyring. Signed-off-by: Eric Snowberg Reviewed-by: Mimi Zohar Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen

integrity: PowerVM support for loading third party code signing keys

2023-08-17T20:12:35+00:00

On secure boot enabled PowerVM LPAR, third party code signing keys are needed during early boot to verify signed third party modules. These third party keys are stored in moduledb object in the Platform KeyStore (PKS). Load third party code signing keys onto .secondary_trusted_keys keyring. Signed-off-by: Nayna Jain Reviewed-and-tested-by: Mimi Zohar Reviewed-by: Jarkko Sakkinen Tested-by: Nageswara R Sastry Signed-off-by: Jarkko Sakkinen