tjh.dev
Linux kernel mirror (for testing)
git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
kernel
os
linux
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