Changes in Kconfig

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

Mon, 16 Oct 2023 00:18:03 +0000

certs: Only allow certs signed by keys on the builtin keyringOriginally the secondary trusted keyring provided a keyring to which extrakeys may be added, provided those keys were not blacklisted and werevouched for by a key built into the kernel or already in the secondarytrusted keyring.On systems with the machine keyring configured, additional keys may alsobe vouched for by a key on the machine keyring.Prevent loading additional certificates directly onto the secondarykeyring, vouched for by keys on the machine keyring, yet allow thesecertificates to be loaded onto other trusted keyrings.Reviewed-by: Jarkko Sakkinen Signed-off-by: Mimi Zohar List of files: /linux-6.15/certs/Kconfig

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

Sun, 22 Oct 2023 18:22:07 +0000

module: enable automatic module signing with FIPS 202 SHA-3Add Kconfig options to use SHA-3 for kernel module signing. 256 sizefor RSA only, and higher sizes for RSA and NIST P-384.Signed-off-by: Dimitri John Ledkov Signed-off-by: Herbert Xu List of files: /linux-6.15/certs/Kconfig

d4f5bfe2 - certs: Limit MODULE_SIG_KEY_TYPE_ECDSA to SHA384 or SHA512

Tue, 10 Oct 2023 21:27:55 +0000

certs: Limit MODULE_SIG_KEY_TYPE_ECDSA to SHA384 or SHA512NIST FIPS 186-5 states that it is recommended that the securitystrength associated with the bit length of n and the security strengthof the hash function be the same, or higher upon agreement. Given NISTP384 curve is used, force using either SHA384 or SHA512.Signed-off-by: Dimitri John Ledkov Signed-off-by: Herbert Xu List of files: /linux-6.15/certs/Kconfig

2154aca2 - certs: make system keyring depend on built-in x509 parser

Mon, 12 Sep 2022 06:52:10 +0000

certs: make system keyring depend on built-in x509 parserCommit e90886291c7c ("certs: make system keyring depend on x509 parser")is not the right fix because x509_load_certificate_list() can be modular.The combination of CONFIG_SYSTEM_TRUSTED_KEYRING=y andCONFIG_X509_CERTIFICATE_PARSER=m still results in the following error: LD .tmp_vmlinux.kallsyms1 ld: certs/system_keyring.o: in function `load_system_certificate_list': system_keyring.c:(.init.text+0x8c): undefined reference to `x509_load_certificate_list' make: *** [Makefile:1169: vmlinux] Error 1Fixes: e90886291c7c ("certs: make system keyring depend on x509 parser")Signed-off-by: Masahiro Yamada Tested-by: Adam Borowski List of files: /linux-6.15/certs/Kconfig

e9088629 - certs: make system keyring depend on x509 parser

Mon, 18 Jul 2022 13:50:34 +0000

certs: make system keyring depend on x509 parserThis code requires x509_load_certificate_list() to be built-in.Fixes: 60050ffe3d77 ("certs: Move load_certificate_list() to be with the asymmetric keys code")Reported-by: kernel test robot Reported-by: Steven Rostedt Link: https://lore.kernel.org/all/202206221515.DqpUuvbQ-lkp@intel.com/Link: https://lore.kernel.org/all/20220712104554.408dbf42@gandalf.local.home/Signed-off-by: Adam Borowski Signed-off-by: Linus Torvalds List of files: /linux-6.15/certs/Kconfig

6364d106 - certs: Allow root user to append signed hashes to the blacklist keyring

Mon, 12 Jul 2021 17:03:13 +0000

certs: Allow root user to append signed hashes to the blacklist keyringAdd a kernel option SYSTEM_BLACKLIST_AUTH_UPDATE to enable the root userto dynamically add new keys to the blacklist keyring. This enables toinvalidate new certificates, either from being loaded in a keyring, orfrom being trusted in a PKCS#7 certificate chain. This also enables toadd new file hashes to be denied by the integrity infrastructure.Being able to untrust a certificate which could have normaly beentrusted is a sensitive operation. This is why adding new hashes to theblacklist keyring is only allowed when these hashes are signed andvouched by the builtin trusted keyring. A blacklist hash is stored as akey description. The PKCS#7 signature of this description must beprovided as the key payload.Marking a certificate as untrusted should be enforced while the systemis running. It is then forbiden to remove such blacklist keys.Update blacklist keyring, blacklist key and revoked certificate accessrights:* allows the root user to search for a specific blacklisted hash, which make sense because the descriptions are already viewable;* forbids key update (blacklist and asymmetric ones);* restricts kernel rights on the blacklist keyring to align with the root user rights.See help in tools/certs/print-cert-tbs-hash.sh .Cc: David Howells Cc: David Woodhouse Cc: Eric Snowberg Cc: Jarkko Sakkinen Signed-off-by: Mickaël Salaün Link: https://lore.kernel.org/r/20210712170313.884724-6-mic@digikod.netReviewed-by: Jarkko Sakkinen Tested-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen List of files: /linux-6.15/certs/Kconfig

addf4663 - certs: Check that builtin blacklist hashes are valid

Mon, 12 Jul 2021 17:03:10 +0000

certs: Check that builtin blacklist hashes are validAdd and use a check-blacklist-hashes.awk script to make sure that thebuiltin blacklist hashes set with CONFIG_SYSTEM_BLACKLIST_HASH_LIST willeffectively be taken into account as blacklisted hashes. This is usefulto debug invalid hash formats, and it make sure that previous hasheswhich could have been loaded in the kernel, but silently ignored, arenow noticed and deal with by the user at kernel build time.This also prevent stricter blacklist key description checking (providedby following commits) to failed for builtin hashes.Update CONFIG_SYSTEM_BLACKLIST_HASH_LIST help to explain the content ofa hash string and how to generate certificate ones.Cc: David Howells Cc: David Woodhouse Cc: Eric Snowberg Cc: Jarkko Sakkinen Signed-off-by: Mickaël Salaün Link: https://lore.kernel.org/r/20210712170313.884724-3-mic@digikod.netReviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen List of files: /linux-6.15/certs/Kconfig

be0d5fa7 - certs: move the 'depends on' to the choice of module signing keys

Fri, 01 Oct 2021 04:01:26 +0000

certs: move the 'depends on' to the choice of module signing keysWhen the condition "MODULE_SIG || (IMA_APPRAISE_MODSIG && MODULES)"is unmet, you cannot choose anything in the choice, but the choicemenu is still displayed in the menuconfig etc.Move the 'depends on' to the choice to hide the meaningless menu.Also delete the redundant 'default'. In a choice, the first entry isthe default.Signed-off-by: Masahiro Yamada List of files: /linux-6.15/certs/Kconfig

a4aed36e - certs: Add support for using elliptic curve keys for signing modules

Tue, 29 Jun 2021 21:34:21 +0000

certs: Add support for using elliptic curve keys for signing modulesAdd support for using elliptic curve keys for signing modules. It usesa NIST P384 (secp384r1) key if the user chooses an elliptic curve keyand will have ECDSA support built into the kernel.Note: A developer choosing an ECDSA key for signing modules should stilldelete the signing key (rm certs/signing_key.*) when building an olderversion of a kernel that only supports RSA keys. Unless kbuild automati-cally detects and generates a new kernel module key, ECDSA-signed kernelmodules will fail signature verification.Cc: David Howells Cc: David Woodhouse Signed-off-by: Stefan Berger Reviewed-by: Jarkko Sakkinen Tested-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen List of files: /linux-6.15/certs/Kconfig

781a5739 - ima: ensure IMA_APPRAISE_MODSIG has necessary dependencies

Fri, 23 Apr 2021 01:16:02 +0000

ima: ensure IMA_APPRAISE_MODSIG has necessary dependenciesIMA_APPRAISE_MODSIG is used for verifying the integrity of both kerneland modules. Enabling IMA_APPRAISE_MODSIG without MODULES causes a buildbreak.Ensure the build time kernel signing key is only generated if bothIMA_APPRAISE_MODSIG and MODULES are enabled.Fixes: 0165f4ca223b ("ima: enable signing of modules with build time generated key")Reported-by: Randy Dunlap Reported-by: Stephen Rothwell Acked-by: Randy Dunlap # build-testedSigned-off-by: Nayna Jain Signed-off-by: Mimi Zohar List of files: /linux-6.15/certs/Kconfig

0165f4ca - ima: enable signing of modules with build time generated key

Fri, 09 Apr 2021 14:35:06 +0000

ima: enable signing of modules with build time generated keyThe kernel build process currently only signs kernel modules whenMODULE_SIG is enabled. Also, sign the kernel modules at build time whenIMA_APPRAISE_MODSIG is enabled.Signed-off-by: Nayna Jain Acked-by: Stefan Berger Signed-off-by: Mimi Zohar List of files: /linux-6.15/certs/Kconfig

d1f04410 - certs: Add ability to preload revocation certs

Fri, 22 Jan 2021 18:10:53 +0000

certs: Add ability to preload revocation certsAdd a new Kconfig option called SYSTEM_REVOCATION_KEYS. If set,this option should be the filename of a PEM-formated file containingX.509 certificates to be included in the default blacklist keyring.DH Changes: - Make the new Kconfig option depend on SYSTEM_REVOCATION_LIST. - Fix SYSTEM_REVOCATION_KEYS=n, but CONFIG_SYSTEM_REVOCATION_LIST=y[1][2]. - Use CONFIG_SYSTEM_REVOCATION_LIST for extract-cert[3]. - Use CONFIG_SYSTEM_REVOCATION_LIST for revocation_certificates.o[3].Signed-off-by: Eric Snowberg Acked-by: Jarkko Sakkinen Signed-off-by: David Howells cc: Randy Dunlap cc: keyrings@vger.kernel.orgLink: https://lore.kernel.org/r/e1c15c74-82ce-3a69-44de-a33af9b320ea@infradead.org/ [1]Link: https://lore.kernel.org/r/20210303034418.106762-1-eric.snowberg@oracle.com/ [2]Link: https://lore.kernel.org/r/20210304175030.184131-1-eric.snowberg@oracle.com/ [3]Link: https://lore.kernel.org/r/20200930201508.35113-3-eric.snowberg@oracle.com/Link: https://lore.kernel.org/r/20210122181054.32635-4-eric.snowberg@oracle.com/ # v5Link: https://lore.kernel.org/r/161428673564.677100.4112098280028451629.stgit@warthog.procyon.org.uk/Link: https://lore.kernel.org/r/161433312452.902181.4146169951896577982.stgit@warthog.procyon.org.uk/ # v2Link: https://lore.kernel.org/r/161529606657.163428.3340689182456495390.stgit@warthog.procyon.org.uk/ # v3 List of files: /linux-6.15/certs/Kconfig

56c58126 - certs: Add EFI_CERT_X509_GUID support for dbx entries

Fri, 22 Jan 2021 18:10:51 +0000

certs: Add EFI_CERT_X509_GUID support for dbx entriesThis fixes CVE-2020-26541.The Secure Boot Forbidden Signature Database, dbx, contains a list of nowrevoked signatures and keys previously approved to boot with UEFI SecureBoot enabled. The dbx is capable of containing any number ofEFI_CERT_X509_SHA256_GUID, EFI_CERT_SHA256_GUID, and EFI_CERT_X509_GUIDentries.Currently when EFI_CERT_X509_GUID are contained in the dbx, the entries areskipped.Add support for EFI_CERT_X509_GUID dbx entries. When a EFI_CERT_X509_GUIDis found, it is added as an asymmetrical key to the .blacklist keyring.Anytime the .platform keyring is used, the keys in the .blacklist keyringare referenced, if a matching key is found, the key will be rejected.[DH: Made the following changes: - Added to have a config option to enable the facility. This allows a Kconfig solution to make sure that pkcs7_validate_trust() is enabled.[1][2] - Moved the functions out from the middle of the blacklist functions. - Added kerneldoc comments.]Signed-off-by: Eric Snowberg Signed-off-by: David Howells Reviewed-by: Jarkko Sakkinen cc: Randy Dunlap cc: Mickaël Salaün cc: Arnd Bergmann cc: keyrings@vger.kernel.orgLink: https://lore.kernel.org/r/20200901165143.10295-1-eric.snowberg@oracle.com/ # rfcLink: https://lore.kernel.org/r/20200909172736.73003-1-eric.snowberg@oracle.com/ # v2Link: https://lore.kernel.org/r/20200911182230.62266-1-eric.snowberg@oracle.com/ # v3Link: https://lore.kernel.org/r/20200916004927.64276-1-eric.snowberg@oracle.com/ # v4Link: https://lore.kernel.org/r/20210122181054.32635-2-eric.snowberg@oracle.com/ # v5Link: https://lore.kernel.org/r/161428672051.677100.11064981943343605138.stgit@warthog.procyon.org.uk/Link: https://lore.kernel.org/r/161433310942.902181.4901864302675874242.stgit@warthog.procyon.org.uk/ # v2Link: https://lore.kernel.org/r/161529605075.163428.14625520893961300757.stgit@warthog.procyon.org.uk/ # v3Link: https://lore.kernel.org/r/bc2c24e3-ed68-2521-0bf4-a1f6be4a895d@infradead.org/ [1]Link: https://lore.kernel.org/r/20210225125638.1841436-1-arnd@kernel.org/ [2] List of files: /linux-6.15/certs/Kconfig

5fb94e9c - docs: Fix some broken references

Tue, 08 May 2018 18:14:57 +0000

docs: Fix some broken referencesAs we move stuff around, some doc references are broken. Fix some ofthem via this script: ./scripts/documentation-file-ref-check --fixManually checked if the produced result is valid, removing a fewfalse-positives.Acked-by: Takashi Iwai Acked-by: Masami Hiramatsu Acked-by: Stephen Boyd Acked-by: Charles Keepax Acked-by: Mathieu Poirier Reviewed-by: Coly Li Signed-off-by: Mauro Carvalho Chehab Acked-by: Jonathan Corbet List of files: /linux-6.15/certs/Kconfig

b2441318 - License cleanup: add SPDX GPL-2.0 license identifier to files with no license

Wed, 01 Nov 2017 14:07:57 +0000

License cleanup: add SPDX GPL-2.0 license identifier to files with no licenseMany source files in the tree are missing licensing information, whichmakes it harder for compliance tools to determine the correct license.By default all files without license information are under the defaultlicense of the kernel, which is GPL version 2.Update the files which contain no license information with the 'GPL-2.0'SPDX license identifier. The SPDX identifier is a legally bindingshorthand, which can be used instead of the full boiler plate text.This patch is based on work done by Thomas Gleixner and Kate Stewart andPhilippe Ombredanne.How this work was done:Patches were generated and checked against linux-4.14-rc6 for a subset ofthe use cases: - file had no licensing information it it. - file was a */uapi/* one with no licensing information in it, - file was a */uapi/* one with existing licensing information,Further patches will be generated in subsequent months to fix up caseswhere non-standard license headers were used, and references to licensehad to be inferred by heuristics based on keywords.The analysis to determine which SPDX License Identifier to be applied toa file was done in a spreadsheet of side by side results from of theoutput of two independent scanners (ScanCode & Windriver) producing SPDXtag:value files created by Philippe Ombredanne. Philippe prepared thebase worksheet, and did an initial spot review of a few 1000 files.The 4.13 kernel was the starting point of the analysis with 60,537 filesassessed. Kate Stewart did a file by file comparison of the scannerresults in the spreadsheet to determine which SPDX license identifier(s)to be applied to the file. She confirmed any determination that was notimmediately clear with lawyers working with the Linux Foundation.Criteria used to select files for SPDX license identifier tagging was: - Files considered eligible had to be source code files. - Make and config files were included as candidates if they contained >5 lines of source - File already had some variant of a license header in it (even if <5 lines).All documentation files were explicitly excluded.The following heuristics were used to determine which SPDX licenseidentifiers to apply. - when both scanners couldn't find any license traces, file was considered to have no license information in it, and the top level COPYING file license applied. For non */uapi/* files that summary was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 11139 and resulted in the first patch in this series. If that file was a */uapi/* path one, it was "GPL-2.0 WITH Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 WITH Linux-syscall-note 930 and resulted in the second patch in this series. - if a file had some form of licensing information in it, and was one of the */uapi/* ones, it was denoted with the Linux-syscall-note if any GPL family license was found in the file or had no licensing in it (per prior point). Results summary: SPDX license identifier # files ---------------------------------------------------|------ GPL-2.0 WITH Linux-syscall-note 270 GPL-2.0+ WITH Linux-syscall-note 169 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17 LGPL-2.1+ WITH Linux-syscall-note 15 GPL-1.0+ WITH Linux-syscall-note 14 ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5 LGPL-2.0+ WITH Linux-syscall-note 4 LGPL-2.1 WITH Linux-syscall-note 3 ((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3 ((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1 and that resulted in the third patch in this series. - when the two scanners agreed on the detected license(s), that became the concluded license(s). - when there was disagreement between the two scanners (one detected a license but the other didn't, or they both detected different licenses) a manual inspection of the file occurred. - In most cases a manual inspection of the information in the file resulted in a clear resolution of the license that should apply (and which scanner probably needed to revisit its heuristics). - When it was not immediately clear, the license identifier was confirmed with lawyers working with the Linux Foundation. - If there was any question as to the appropriate license identifier, the file was flagged for further research and to be revisited later in time.In total, over 70 hours of logged manual review was done on thespreadsheet to determine the SPDX license identifiers to apply to thesource files by Kate, Philippe, Thomas and, in some cases, confirmationby lawyers working with the Linux Foundation.Kate also obtained a third independent scan of the 4.13 code base fromFOSSology, and compared selected files where the other two scannersdisagreed against that SPDX file, to see if there was new insights. TheWindriver scanner is based on an older version of FOSSology in part, sothey are related.Thomas did random spot checks in about 500 files from the spreadsheetsfor the uapi headers and agreed with SPDX license identifier in thefiles he inspected. For the non-uapi files Thomas did random spot checksin about 15000 files.In initial set of patches against 4.14-rc6, 3 files were found to havecopy/paste license identifier errors, and have been fixed to reflect thecorrect identifier.Additionally Philippe spent 10 hours this week doing a detailed manualinspection and review of the 12,461 patched files from the initial patchversion early this week with: - a full scancode scan run, collecting the matched texts, detected license ids and scores - reviewing anything where there was a license detected (about 500+ files) to ensure that the applied SPDX license was correct - reviewing anything where there was no detection but the patch license was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied SPDX license was correctThis produced a worksheet with 20 files needing minor correction. Thisworksheet was then exported into 3 different .csv files for thedifferent types of files to be modified.These .csv files were then reviewed by Greg. Thomas wrote a script toparse the csv files and add the proper SPDX tag to the file, in theformat that the file expected. This script was further refined by Gregbased on the output to detect more types of files automatically and todistinguish between header and source .c files (which need differentcomment types.) Finally Greg ran the script using the .csv files togenerate the patches.Reviewed-by: Kate Stewart Reviewed-by: Philippe Ombredanne Reviewed-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman List of files: /linux-6.15/certs/Kconfig

734114f8 - KEYS: Add a system blacklist keyring

Mon, 03 Apr 2017 15:07:24 +0000

KEYS: Add a system blacklist keyringAdd the following: (1) A new system keyring that is used to store information about blacklisted certificates and signatures. (2) A new key type (called 'blacklist') that is used to store a blacklisted hash in its description as a hex string. The key accepts no payload. (3) The ability to configure a list of blacklisted hashes into the kernel at build time. This is done by setting CONFIG_SYSTEM_BLACKLIST_HASH_LIST to the filename of a list of hashes that are in the form: "", "", ..., "" where each is a hex string representation of the hash and must include all necessary leading zeros to pad the hash to the right size.The above are enabled with CONFIG_SYSTEM_BLACKLIST_KEYRING.Once the kernel is booted, the blacklist keyring can be listed: root@andromeda ~]# keyctl show %:.blacklist Keyring 723359729 ---lswrv 0 0 keyring: .blacklist 676257228 ---lswrv 0 0 \_ blacklist: 123412341234c55c1dcc601ab8e172917706aa32fb5eaf826813547fdf02dd46The blacklist cannot currently be modified by userspace, but it will bepossible to load it, for example, from the UEFI blacklist database.A later commit will make it possible to load blacklisted asymmetric keys inhere too.Signed-off-by: David Howells List of files: /linux-6.15/certs/Kconfig

d3bfe841 - certs: Add a secondary system keyring that can be added to dynamically

Wed, 06 Apr 2016 15:14:27 +0000

certs: Add a secondary system keyring that can be added to dynamicallyAdd a secondary system keyring that can be added to by root whilst thesystem is running - provided the key being added is vouched for by a keybuilt into the kernel or already added to the secondary keyring.Rename .system_keyring to .builtin_trusted_keys to distinguish it moreobviously from the new keyring (called .secondary_trusted_keys).The new keyring needs to be enabled with CONFIG_SECONDARY_TRUSTED_KEYRING.If the secondary keyring is enabled, a link is created from that to.builtin_trusted_keys so that the the latter will automatically be searchedtoo if the secondary keyring is searched.Signed-off-by: David Howells List of files: /linux-6.15/certs/Kconfig

99716b7c - KEYS: Make the system trusted keyring depend on the asymmetric key type

Wed, 06 Apr 2016 15:14:26 +0000

KEYS: Make the system trusted keyring depend on the asymmetric key typeMake the system trusted keyring depend on the asymmetric key type asthere's not a lot of point having it if you can't then load asymmetric keysonto it.This requires the ASYMMETRIC_KEY_TYPE to be made a bool, not a tristate, asthe Kconfig language doesn't then correctly force ASYMMETRIC_KEY_TYPE to'y' rather than 'm' if SYSTEM_TRUSTED_KEYRING is 'y'.Making SYSTEM_TRUSTED_KEYRING *select* ASYMMETRIC_KEY_TYPE instead doesn'twork as the Kconfig interpreter then wrongly complains about dependencyloops.Signed-off-by: David Howells List of files: /linux-6.15/certs/Kconfig

c4c36105 - KEYS: Reserve an extra certificate symbol for inserting without recompiling

Tue, 24 Nov 2015 21:18:05 +0000

KEYS: Reserve an extra certificate symbol for inserting without recompilingPlace a system_extra_cert buffer of configurable size, right after thesystem_certificate_list, so that inserted keys can be readily processed bythe existing mechanism. Added script takes a key file and a kernel imageand inserts its contents to the reserved area. Thesystem_certificate_list_size is also adjusted accordingly.Call the script as: scripts/insert-sys-cert -b -c If vmlinux has no symbol table, supply System.map file with -s flag.Subsequent runs replace the previously inserted key, instead of appendingthe new one.Signed-off-by: Mehmet Kayaalp Signed-off-by: David Howells Acked-by: Mimi Zohar List of files: /linux-6.15/certs/Kconfig

cfc411e7 - Move certificate handling to its own directory

Fri, 14 Aug 2015 14:20:41 +0000

Move certificate handling to its own directoryMove certificate handling out of the kernel/ directory and into a certs/directory to get all the weird stuff in one place and move the generatedsigning keys into this directory.Signed-off-by: David Howells Reviewed-by: David Woodhouse List of files: /linux-6.15/certs/Kconfig