| 1 | # SPDX-License-Identifier: GPL-2.0-only |
| 2 | menuconfig MODULES |
| 3 | bool "Enable loadable module support" |
| 4 | modules |
| 5 | help |
| 6 | Kernel modules are small pieces of compiled code which can |
| 7 | be inserted in the running kernel, rather than being |
| 8 | permanently built into the kernel. You use the "modprobe" |
| 9 | tool to add (and sometimes remove) them. If you say Y here, |
| 10 | many parts of the kernel can be built as modules (by |
| 11 | answering M instead of Y where indicated): this is most |
| 12 | useful for infrequently used options which are not required |
| 13 | for booting. For more information, see the man pages for |
| 14 | modprobe, lsmod, modinfo, insmod and rmmod. |
| 15 | |
| 16 | If you say Y here, you will need to run "make |
| 17 | modules_install" to put the modules under /lib/modules/ |
| 18 | where modprobe can find them (you may need to be root to do |
| 19 | this). |
| 20 | |
| 21 | If unsure, say Y. |
| 22 | |
| 23 | if MODULES |
| 24 | |
| 25 | config MODULE_DEBUGFS |
| 26 | bool |
| 27 | |
| 28 | config MODULE_DEBUG |
| 29 | bool "Module debugging" |
| 30 | depends on DEBUG_FS |
| 31 | help |
| 32 | Allows you to enable / disable features which can help you debug |
| 33 | modules. You don't need these options on production systems. |
| 34 | |
| 35 | if MODULE_DEBUG |
| 36 | |
| 37 | config MODULE_STATS |
| 38 | bool "Module statistics" |
| 39 | depends on DEBUG_FS |
| 40 | select MODULE_DEBUGFS |
| 41 | help |
| 42 | This option allows you to maintain a record of module statistics. |
| 43 | For example, size of all modules, average size, text size, a list |
| 44 | of failed modules and the size for each of those. For failed |
| 45 | modules we keep track of modules which failed due to either the |
| 46 | existing module taking too long to load or that module was already |
| 47 | loaded. |
| 48 | |
| 49 | You should enable this if you are debugging production loads |
| 50 | and want to see if userspace or the kernel is doing stupid things |
| 51 | with loading modules when it shouldn't or if you want to help |
| 52 | optimize userspace / kernel space module autoloading schemes. |
| 53 | You might want to do this because failed modules tend to use |
| 54 | up significant amount of memory, and so you'd be doing everyone a |
| 55 | favor in avoiding these failures proactively. |
| 56 | |
| 57 | This functionality is also useful for those experimenting with |
| 58 | module .text ELF section optimization. |
| 59 | |
| 60 | If unsure, say N. |
| 61 | |
| 62 | config MODULE_DEBUG_AUTOLOAD_DUPS |
| 63 | bool "Debug duplicate modules with auto-loading" |
| 64 | help |
| 65 | Module autoloading allows in-kernel code to request modules through |
| 66 | the *request_module*() API calls. This in turn just calls userspace |
| 67 | modprobe. Although modprobe checks to see if a module is already |
| 68 | loaded before trying to load a module there is a small time window in |
| 69 | which multiple duplicate requests can end up in userspace and multiple |
| 70 | modprobe calls race calling finit_module() around the same time for |
| 71 | duplicate modules. The finit_module() system call can consume in the |
| 72 | worst case more than twice the respective module size in virtual |
| 73 | memory for each duplicate module requests. Although duplicate module |
| 74 | requests are non-fatal virtual memory is a limited resource and each |
| 75 | duplicate module request ends up just unnecessarily straining virtual |
| 76 | memory. |
| 77 | |
| 78 | This debugging facility will create pr_warn() splats for duplicate |
| 79 | module requests to help identify if module auto-loading may be the |
| 80 | culprit to your early boot virtual memory pressure. Since virtual |
| 81 | memory abuse caused by duplicate module requests could render a |
| 82 | system unusable this functionality will also converge races in |
| 83 | requests for the same module to a single request. You can boot with |
| 84 | the module.enable_dups_trace=1 kernel parameter to use WARN_ON() |
| 85 | instead of the pr_warn(). |
| 86 | |
| 87 | If the first module request used request_module_nowait() we cannot |
| 88 | use that as the anchor to wait for duplicate module requests, since |
| 89 | users of request_module() do want a proper return value. If a call |
| 90 | for the same module happened earlier with request_module() though, |
| 91 | then a duplicate request_module_nowait() would be detected. The |
| 92 | non-wait request_module() call is synchronous and waits until modprobe |
| 93 | completes. Subsequent auto-loading requests for the same module do |
| 94 | not trigger a new finit_module() calls and do not strain virtual |
| 95 | memory, and so as soon as modprobe successfully completes we remove |
| 96 | tracking for duplicates for that module. |
| 97 | |
| 98 | Enable this functionality to try to debug virtual memory abuse during |
| 99 | boot on systems which are failing to boot or if you suspect you may be |
| 100 | straining virtual memory during boot, and you want to identify if the |
| 101 | abuse was due to module auto-loading. These issues are currently only |
| 102 | known to occur on systems with many CPUs (over 400) and is likely the |
| 103 | result of udev issuing duplicate module requests for each CPU, and so |
| 104 | module auto-loading is not the culprit. There may very well still be |
| 105 | many duplicate module auto-loading requests which could be optimized |
| 106 | for and this debugging facility can be used to help identify them. |
| 107 | |
| 108 | Only enable this for debugging system functionality, never have it |
| 109 | enabled on real systems. |
| 110 | |
| 111 | config MODULE_DEBUG_AUTOLOAD_DUPS_TRACE |
| 112 | bool "Force full stack trace when duplicates are found" |
| 113 | depends on MODULE_DEBUG_AUTOLOAD_DUPS |
| 114 | help |
| 115 | Enabling this will force a full stack trace for duplicate module |
| 116 | auto-loading requests using WARN_ON() instead of pr_warn(). You |
| 117 | should keep this disabled at all times unless you are a developer |
| 118 | and are doing a manual inspection and want to debug exactly why |
| 119 | these duplicates occur. |
| 120 | |
| 121 | endif # MODULE_DEBUG |
| 122 | |
| 123 | config MODULE_FORCE_LOAD |
| 124 | bool "Forced module loading" |
| 125 | default n |
| 126 | help |
| 127 | Allow loading of modules without version information (ie. modprobe |
| 128 | --force). Forced module loading sets the 'F' (forced) taint flag and |
| 129 | is usually a really bad idea. |
| 130 | |
| 131 | config MODULE_UNLOAD |
| 132 | bool "Module unloading" |
| 133 | help |
| 134 | Without this option you will not be able to unload any |
| 135 | modules (note that some modules may not be unloadable |
| 136 | anyway), which makes your kernel smaller, faster |
| 137 | and simpler. If unsure, say Y. |
| 138 | |
| 139 | config MODULE_FORCE_UNLOAD |
| 140 | bool "Forced module unloading" |
| 141 | depends on MODULE_UNLOAD |
| 142 | help |
| 143 | This option allows you to force a module to unload, even if the |
| 144 | kernel believes it is unsafe: the kernel will remove the module |
| 145 | without waiting for anyone to stop using it (using the -f option to |
| 146 | rmmod). This is mainly for kernel developers and desperate users. |
| 147 | If unsure, say N. |
| 148 | |
| 149 | config MODULE_UNLOAD_TAINT_TRACKING |
| 150 | bool "Tainted module unload tracking" |
| 151 | depends on MODULE_UNLOAD |
| 152 | select MODULE_DEBUGFS |
| 153 | help |
| 154 | This option allows you to maintain a record of each unloaded |
| 155 | module that tainted the kernel. In addition to displaying a |
| 156 | list of linked (or loaded) modules e.g. on detection of a bad |
| 157 | page (see bad_page()), the aforementioned details are also |
| 158 | shown. If unsure, say N. |
| 159 | |
| 160 | config MODVERSIONS |
| 161 | bool "Module versioning support" |
| 162 | help |
| 163 | Usually, you have to use modules compiled with your kernel. |
| 164 | Saying Y here makes it sometimes possible to use modules |
| 165 | compiled for different kernels, by adding enough information |
| 166 | to the modules to (hopefully) spot any changes which would |
| 167 | make them incompatible with the kernel you are running. If |
| 168 | unsure, say N. |
| 169 | |
| 170 | config ASM_MODVERSIONS |
| 171 | bool |
| 172 | default HAVE_ASM_MODVERSIONS && MODVERSIONS |
| 173 | help |
| 174 | This enables module versioning for exported symbols also from |
| 175 | assembly. This can be enabled only when the target architecture |
| 176 | supports it. |
| 177 | |
| 178 | config MODULE_SRCVERSION_ALL |
| 179 | bool "Source checksum for all modules" |
| 180 | help |
| 181 | Modules which contain a MODULE_VERSION get an extra "srcversion" |
| 182 | field inserted into their modinfo section, which contains a |
| 183 | sum of the source files which made it. This helps maintainers |
| 184 | see exactly which source was used to build a module (since |
| 185 | others sometimes change the module source without updating |
| 186 | the version). With this option, such a "srcversion" field |
| 187 | will be created for all modules. If unsure, say N. |
| 188 | |
| 189 | config MODULE_SIG |
| 190 | bool "Module signature verification" |
| 191 | select MODULE_SIG_FORMAT |
| 192 | help |
| 193 | Check modules for valid signatures upon load: the signature |
| 194 | is simply appended to the module. For more information see |
| 195 | <file:Documentation/admin-guide/module-signing.rst>. |
| 196 | |
| 197 | Note that this option adds the OpenSSL development packages as a |
| 198 | kernel build dependency so that the signing tool can use its crypto |
| 199 | library. |
| 200 | |
| 201 | You should enable this option if you wish to use either |
| 202 | CONFIG_SECURITY_LOCKDOWN_LSM or lockdown functionality imposed via |
| 203 | another LSM - otherwise unsigned modules will be loadable regardless |
| 204 | of the lockdown policy. |
| 205 | |
| 206 | !!!WARNING!!! If you enable this option, you MUST make sure that the |
| 207 | module DOES NOT get stripped after being signed. This includes the |
| 208 | debuginfo strip done by some packagers (such as rpmbuild) and |
| 209 | inclusion into an initramfs that wants the module size reduced. |
| 210 | |
| 211 | config MODULE_SIG_FORCE |
| 212 | bool "Require modules to be validly signed" |
| 213 | depends on MODULE_SIG |
| 214 | help |
| 215 | Reject unsigned modules or signed modules for which we don't have a |
| 216 | key. Without this, such modules will simply taint the kernel. |
| 217 | |
| 218 | config MODULE_SIG_ALL |
| 219 | bool "Automatically sign all modules" |
| 220 | default y |
| 221 | depends on MODULE_SIG || IMA_APPRAISE_MODSIG |
| 222 | help |
| 223 | Sign all modules during make modules_install. Without this option, |
| 224 | modules must be signed manually, using the scripts/sign-file tool. |
| 225 | |
| 226 | comment "Do not forget to sign required modules with scripts/sign-file" |
| 227 | depends on MODULE_SIG_FORCE && !MODULE_SIG_ALL |
| 228 | |
| 229 | choice |
| 230 | prompt "Which hash algorithm should modules be signed with?" |
| 231 | depends on MODULE_SIG || IMA_APPRAISE_MODSIG |
| 232 | help |
| 233 | This determines which sort of hashing algorithm will be used during |
| 234 | signature generation. This algorithm _must_ be built into the kernel |
| 235 | directly so that signature verification can take place. It is not |
| 236 | possible to load a signed module containing the algorithm to check |
| 237 | the signature on that module. |
| 238 | |
| 239 | config MODULE_SIG_SHA1 |
| 240 | bool "Sign modules with SHA-1" |
| 241 | select CRYPTO_SHA1 |
| 242 | |
| 243 | config MODULE_SIG_SHA256 |
| 244 | bool "Sign modules with SHA-256" |
| 245 | select CRYPTO_SHA256 |
| 246 | |
| 247 | config MODULE_SIG_SHA384 |
| 248 | bool "Sign modules with SHA-384" |
| 249 | select CRYPTO_SHA512 |
| 250 | |
| 251 | config MODULE_SIG_SHA512 |
| 252 | bool "Sign modules with SHA-512" |
| 253 | select CRYPTO_SHA512 |
| 254 | |
| 255 | config MODULE_SIG_SHA3_256 |
| 256 | bool "Sign modules with SHA3-256" |
| 257 | select CRYPTO_SHA3 |
| 258 | |
| 259 | config MODULE_SIG_SHA3_384 |
| 260 | bool "Sign modules with SHA3-384" |
| 261 | select CRYPTO_SHA3 |
| 262 | |
| 263 | config MODULE_SIG_SHA3_512 |
| 264 | bool "Sign modules with SHA3-512" |
| 265 | select CRYPTO_SHA3 |
| 266 | |
| 267 | endchoice |
| 268 | |
| 269 | config MODULE_SIG_HASH |
| 270 | string |
| 271 | depends on MODULE_SIG || IMA_APPRAISE_MODSIG |
| 272 | default "sha1" if MODULE_SIG_SHA1 |
| 273 | default "sha256" if MODULE_SIG_SHA256 |
| 274 | default "sha384" if MODULE_SIG_SHA384 |
| 275 | default "sha512" if MODULE_SIG_SHA512 |
| 276 | default "sha3-256" if MODULE_SIG_SHA3_256 |
| 277 | default "sha3-384" if MODULE_SIG_SHA3_384 |
| 278 | default "sha3-512" if MODULE_SIG_SHA3_512 |
| 279 | |
| 280 | choice |
| 281 | prompt "Module compression mode" |
| 282 | help |
| 283 | This option allows you to choose the algorithm which will be used to |
| 284 | compress modules when 'make modules_install' is run. (or, you can |
| 285 | choose to not compress modules at all.) |
| 286 | |
| 287 | External modules will also be compressed in the same way during the |
| 288 | installation. |
| 289 | |
| 290 | For modules inside an initrd or initramfs, it's more efficient to |
| 291 | compress the whole initrd or initramfs instead. |
| 292 | |
| 293 | This is fully compatible with signed modules. |
| 294 | |
| 295 | Please note that the tool used to load modules needs to support the |
| 296 | corresponding algorithm. module-init-tools MAY support gzip, and kmod |
| 297 | MAY support gzip, xz and zstd. |
| 298 | |
| 299 | Your build system needs to provide the appropriate compression tool |
| 300 | to compress the modules. |
| 301 | |
| 302 | If in doubt, select 'None'. |
| 303 | |
| 304 | config MODULE_COMPRESS_NONE |
| 305 | bool "None" |
| 306 | help |
| 307 | Do not compress modules. The installed modules are suffixed |
| 308 | with .ko. |
| 309 | |
| 310 | config MODULE_COMPRESS_GZIP |
| 311 | bool "GZIP" |
| 312 | help |
| 313 | Compress modules with GZIP. The installed modules are suffixed |
| 314 | with .ko.gz. |
| 315 | |
| 316 | config MODULE_COMPRESS_XZ |
| 317 | bool "XZ" |
| 318 | help |
| 319 | Compress modules with XZ. The installed modules are suffixed |
| 320 | with .ko.xz. |
| 321 | |
| 322 | config MODULE_COMPRESS_ZSTD |
| 323 | bool "ZSTD" |
| 324 | help |
| 325 | Compress modules with ZSTD. The installed modules are suffixed |
| 326 | with .ko.zst. |
| 327 | |
| 328 | endchoice |
| 329 | |
| 330 | config MODULE_DECOMPRESS |
| 331 | bool "Support in-kernel module decompression" |
| 332 | depends on MODULE_COMPRESS_GZIP || MODULE_COMPRESS_XZ || MODULE_COMPRESS_ZSTD |
| 333 | select ZLIB_INFLATE if MODULE_COMPRESS_GZIP |
| 334 | select XZ_DEC if MODULE_COMPRESS_XZ |
| 335 | select ZSTD_DECOMPRESS if MODULE_COMPRESS_ZSTD |
| 336 | help |
| 337 | |
| 338 | Support for decompressing kernel modules by the kernel itself |
| 339 | instead of relying on userspace to perform this task. Useful when |
| 340 | load pinning security policy is enabled. |
| 341 | |
| 342 | If unsure, say N. |
| 343 | |
| 344 | config MODULE_ALLOW_MISSING_NAMESPACE_IMPORTS |
| 345 | bool "Allow loading of modules with missing namespace imports" |
| 346 | help |
| 347 | Symbols exported with EXPORT_SYMBOL_NS*() are considered exported in |
| 348 | a namespace. A module that makes use of a symbol exported with such a |
| 349 | namespace is required to import the namespace via MODULE_IMPORT_NS(). |
| 350 | There is no technical reason to enforce correct namespace imports, |
| 351 | but it creates consistency between symbols defining namespaces and |
| 352 | users importing namespaces they make use of. This option relaxes this |
| 353 | requirement and lifts the enforcement when loading a module. |
| 354 | |
| 355 | If unsure, say N. |
| 356 | |
| 357 | config MODPROBE_PATH |
| 358 | string "Path to modprobe binary" |
| 359 | default "/sbin/modprobe" |
| 360 | help |
| 361 | When kernel code requests a module, it does so by calling |
| 362 | the "modprobe" userspace utility. This option allows you to |
| 363 | set the path where that binary is found. This can be changed |
| 364 | at runtime via the sysctl file |
| 365 | /proc/sys/kernel/modprobe. Setting this to the empty string |
| 366 | removes the kernel's ability to request modules (but |
| 367 | userspace can still load modules explicitly). |
| 368 | |
| 369 | config TRIM_UNUSED_KSYMS |
| 370 | bool "Trim unused exported kernel symbols" |
| 371 | help |
| 372 | The kernel and some modules make many symbols available for |
| 373 | other modules to use via EXPORT_SYMBOL() and variants. Depending |
| 374 | on the set of modules being selected in your kernel configuration, |
| 375 | many of those exported symbols might never be used. |
| 376 | |
| 377 | This option allows for unused exported symbols to be dropped from |
| 378 | the build. In turn, this provides the compiler more opportunities |
| 379 | (especially when using LTO) for optimizing the code and reducing |
| 380 | binary size. This might have some security advantages as well. |
| 381 | |
| 382 | If unsure, or if you need to build out-of-tree modules, say N. |
| 383 | |
| 384 | config UNUSED_KSYMS_WHITELIST |
| 385 | string "Whitelist of symbols to keep in ksymtab" |
| 386 | depends on TRIM_UNUSED_KSYMS |
| 387 | help |
| 388 | By default, all unused exported symbols will be un-exported from the |
| 389 | build when TRIM_UNUSED_KSYMS is selected. |
| 390 | |
| 391 | UNUSED_KSYMS_WHITELIST allows to whitelist symbols that must be kept |
| 392 | exported at all times, even in absence of in-tree users. The value to |
| 393 | set here is the path to a text file containing the list of symbols, |
| 394 | one per line. The path can be absolute, or relative to the kernel |
| 395 | source tree. |
| 396 | |
| 397 | config MODULES_TREE_LOOKUP |
| 398 | def_bool y |
| 399 | depends on PERF_EVENTS || TRACING || CFI_CLANG |
| 400 | |
| 401 | endif # MODULES |