1# SPDX-License-Identifier: GPL-2.0 2menu "Certificates for signature checking" 3 4config MODULE_SIG_KEY 5 string "File name or PKCS#11 URI of module signing key" 6 default "certs/signing_key.pem" 7 depends on MODULE_SIG || (IMA_APPRAISE_MODSIG && MODULES) 8 help 9 Provide the file name of a private key/certificate in PEM format, 10 or a PKCS#11 URI according to RFC7512. The file should contain, or 11 the URI should identify, both the certificate and its corresponding 12 private key. 13 14 If this option is unchanged from its default "certs/signing_key.pem", 15 then the kernel will automatically generate the private key and 16 certificate as described in Documentation/admin-guide/module-signing.rst 17 18choice 19 prompt "Type of module signing key to be generated" 20 depends on MODULE_SIG || (IMA_APPRAISE_MODSIG && MODULES) 21 help 22 The type of module signing key type to generate. This option 23 does not apply if a #PKCS11 URI is used. 24 25config MODULE_SIG_KEY_TYPE_RSA 26 bool "RSA" 27 help 28 Use an RSA key for module signing. 29 30config MODULE_SIG_KEY_TYPE_ECDSA 31 bool "ECDSA" 32 select CRYPTO_ECDSA 33 depends on !(MODULE_SIG_SHA256 || MODULE_SIG_SHA3_256) 34 help 35 Use an elliptic curve key (NIST P384) for module signing. Use 36 a strong hash of same or higher bit length, i.e. sha384 or 37 sha512 for hashing modules. 38 39 Note: Remove all ECDSA signing keys, e.g. certs/signing_key.pem, 40 when falling back to building Linux 5.14 and older kernels. 41 42config MODULE_SIG_KEY_TYPE_MLDSA_44 43 bool "ML-DSA-44" 44 select CRYPTO_MLDSA 45 depends on OPENSSL_SUPPORTS_ML_DSA 46 help 47 Use an ML-DSA-44 key (NIST FIPS 204) for module signing. ML-DSA 48 support requires OpenSSL-3.5 minimum; preferably OpenSSL-4+. With 49 the latter, the entire module body will be signed; with the former, 50 signedAttrs will be used as it lacks support for CMS_NOATTR with 51 ML-DSA. 52 53config MODULE_SIG_KEY_TYPE_MLDSA_65 54 bool "ML-DSA-65" 55 select CRYPTO_MLDSA 56 depends on OPENSSL_SUPPORTS_ML_DSA 57 help 58 Use an ML-DSA-65 key (NIST FIPS 204) for module signing. ML-DSA 59 support requires OpenSSL-3.5 minimum; preferably OpenSSL-4+. With 60 the latter, the entire module body will be signed; with the former, 61 signedAttrs will be used as it lacks support for CMS_NOATTR with 62 ML-DSA. 63 64config MODULE_SIG_KEY_TYPE_MLDSA_87 65 bool "ML-DSA-87" 66 select CRYPTO_MLDSA 67 depends on OPENSSL_SUPPORTS_ML_DSA 68 help 69 Use an ML-DSA-87 key (NIST FIPS 204) for module signing. ML-DSA 70 support requires OpenSSL-3.5 minimum; preferably OpenSSL-4+. With 71 the latter, the entire module body will be signed; with the former, 72 signedAttrs will be used as it lacks support for CMS_NOATTR with 73 ML-DSA. 74 75endchoice 76 77config SYSTEM_TRUSTED_KEYRING 78 bool "Provide system-wide ring of trusted keys" 79 depends on KEYS 80 depends on ASYMMETRIC_KEY_TYPE 81 depends on X509_CERTIFICATE_PARSER = y 82 help 83 Provide a system keyring to which trusted keys can be added. Keys in 84 the keyring are considered to be trusted. Keys may be added at will 85 by the kernel from compiled-in data and from hardware key stores, but 86 userspace may only add extra keys if those keys can be verified by 87 keys already in the keyring. 88 89 Keys in this keyring are used by module signature checking. 90 91config SYSTEM_TRUSTED_KEYS 92 string "Additional X.509 keys for default system keyring" 93 depends on SYSTEM_TRUSTED_KEYRING 94 help 95 If set, this option should be the filename of a PEM-formatted file 96 containing trusted X.509 certificates to be included in the default 97 system keyring. Any certificate used for module signing is implicitly 98 also trusted. 99 100 NOTE: If you previously provided keys for the system keyring in the 101 form of DER-encoded *.x509 files in the top-level build directory, 102 those are no longer used. You will need to set this option instead. 103 104config SYSTEM_EXTRA_CERTIFICATE 105 bool "Reserve area for inserting a certificate without recompiling" 106 depends on SYSTEM_TRUSTED_KEYRING 107 help 108 If set, space for an extra certificate will be reserved in the kernel 109 image. This allows introducing a trusted certificate to the default 110 system keyring without recompiling the kernel. 111 112config SYSTEM_EXTRA_CERTIFICATE_SIZE 113 int "Number of bytes to reserve for the extra certificate" 114 depends on SYSTEM_EXTRA_CERTIFICATE 115 default 4096 116 help 117 This is the number of bytes reserved in the kernel image for a 118 certificate to be inserted. 119 120config SECONDARY_TRUSTED_KEYRING 121 bool "Provide a keyring to which extra trustable keys may be added" 122 depends on SYSTEM_TRUSTED_KEYRING 123 help 124 If set, provide a keyring to which extra keys may be added, provided 125 those keys are not blacklisted and are vouched for by a key built 126 into the kernel, machine keyring (if configured), or already in the 127 secondary trusted keyring. 128 129config SECONDARY_TRUSTED_KEYRING_SIGNED_BY_BUILTIN 130 bool "Only allow additional certs signed by keys on the builtin trusted keyring" 131 depends on SECONDARY_TRUSTED_KEYRING 132 help 133 If set, only certificates signed by keys on the builtin trusted 134 keyring may be loaded onto the secondary trusted keyring. 135 136 Note: The machine keyring, if configured, will be linked to the 137 secondary keyring. When enabling this option, it is recommended 138 to also configure INTEGRITY_CA_MACHINE_KEYRING_MAX to prevent 139 linking code signing keys with imputed trust to the secondary 140 trusted keyring. 141 142config SYSTEM_BLACKLIST_KEYRING 143 bool "Provide system-wide ring of blacklisted keys" 144 depends on KEYS 145 help 146 Provide a system keyring to which blacklisted keys can be added. 147 Keys in the keyring are considered entirely untrusted. Keys in this 148 keyring are used by the module signature checking to reject loading 149 of modules signed with a blacklisted key. 150 151config SYSTEM_BLACKLIST_HASH_LIST 152 string "Hashes to be preloaded into the system blacklist keyring" 153 depends on SYSTEM_BLACKLIST_KEYRING 154 help 155 If set, this option should be the filename of a list of hashes in the 156 form "<hash>", "<hash>", ... . This will be included into a C 157 wrapper to incorporate the list into the kernel. Each <hash> must be a 158 string starting with a prefix ("tbs" or "bin"), then a colon (":"), and 159 finally an even number of hexadecimal lowercase characters (up to 128). 160 Certificate hashes can be generated with 161 tools/certs/print-cert-tbs-hash.sh . 162 163config SYSTEM_REVOCATION_LIST 164 bool "Provide system-wide ring of revocation certificates" 165 depends on SYSTEM_BLACKLIST_KEYRING 166 depends on PKCS7_MESSAGE_PARSER=y 167 help 168 If set, this allows revocation certificates to be stored in the 169 blacklist keyring and implements a hook whereby a PKCS#7 message can 170 be checked to see if it matches such a certificate. 171 172config SYSTEM_REVOCATION_KEYS 173 string "X.509 certificates to be preloaded into the system blacklist keyring" 174 depends on SYSTEM_REVOCATION_LIST 175 help 176 If set, this option should be the filename of a PEM-formatted file 177 containing X.509 certificates to be included in the default blacklist 178 keyring. 179 180config SYSTEM_BLACKLIST_AUTH_UPDATE 181 bool "Allow root to add signed blacklist keys" 182 depends on SYSTEM_BLACKLIST_KEYRING 183 depends on SYSTEM_DATA_VERIFICATION 184 help 185 If set, provide the ability to load new blacklist keys at run time if 186 they are signed and vouched by a certificate from the builtin trusted 187 keyring. The PKCS#7 signature of the description is set in the key 188 payload. Blacklist keys cannot be removed. 189 190config OPENSSL_SUPPORTS_ML_DSA 191 def_bool $(success, openssl list -key-managers | grep -q ML-DSA-87) 192 help 193 Support for ML-DSA-44/65/87 was added in openssl-3.5, so as long 194 as older versions are supported, the key types may only be 195 set after testing the installed binary for support. 196 197endmenu 198