summaryrefslogtreecommitdiff
path: root/drivers/char/ipmi/ipmb_dev_int.c
AgeCommit message (Expand)Author
2025-03-13ipmi: ipmb: Add check devm_kasprintf() returned valueCharles Han
2020-02-19drivers: ipmi: fix off-by-one bounds check that leads to a out-of-bounds writeColin Ian King
2019-07-24Fix uninitialized variable in ipmb_dev_int.cAsmaa Mnebhi
2019-06-23fix platform_no_drv_owner.cocci warningskbuild test robot
2019-06-19ipmi: ipmb: don't allocate i2c_client on stackArnd Bergmann
2019-06-10Add support for IPMB driverAsmaa Mnebhi
d-by: Jarkko Sakkinen <jarkko@kernel.org> Tested-by: R Nageswara Sastry <rnsastry@linux.ibm.com> Reviewed-by: Neal Gompa <neal@gompa.dev> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org> 2024-09-20sign-file,extract-cert: move common SSL helper functions to a headerJan Stancek Couple error handling helpers are repeated in both tools, so move them to a common header. Signed-off-by: Jan Stancek <jstancek@redhat.com> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Tested-by: R Nageswara Sastry <rnsastry@linux.ibm.com> Reviewed-by: Neal Gompa <neal@gompa.dev> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org> 2024-05-10kbuild: use $(src) instead of $(srctree)/$(src) for source directoryMasahiro Yamada 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 <masahiroy@kernel.org> Reviewed-by: Nicolas Schier <nicolas@fjasle.eu> 2023-11-02Merge tag 'v6.7-p1' of ↵Linus Torvalds git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 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 ... 2023-10-31certs: Only allow certs signed by keys on the builtin keyringMimi Zohar 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 <jarkko@kernel.org> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com> 2023-10-27module: enable automatic module signing with FIPS 202 SHA-3Dimitri John Ledkov 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 <dimitri.ledkov@canonical.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> 2023-10-20certs: Limit MODULE_SIG_KEY_TYPE_ECDSA to SHA384 or SHA512Dimitri John Ledkov 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 <dimitri.ledkov@canonical.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> 2023-08-17certs: Reference revocation list for all keyringsEric Snowberg 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 <eric.snowberg@oracle.com> Reviewed-by: Mimi Zohar <zohar@linux.ibm.com> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org> 2023-08-17integrity: PowerVM support for loading third party code signing keysNayna Jain 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 <nayna@linux.ibm.com> Reviewed-and-tested-by: Mimi Zohar <zohar@linux.ibm.com> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Tested-by: Nageswara R Sastry <rnsastry@linux.ibm.com> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org> 2023-08-17KEYS: DigitalSignature link restrictionEric Snowberg Add a new link restriction. Restrict the addition of keys in a keyring based on the key having digitalSignature usage set. Additionally, verify the new certificate against the ones in the system keyrings. Add two additional functions to use the new restriction within either the builtin or secondary keyrings. [jarkko@kernel.org: Fix checkpatch.pl --strict issues] Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com> Reviewed-and-tested-by: Mimi Zohar <zohar@linux.ibm.com> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>