| 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405 |
- # SPDX-License-Identifier: GPL-2.0-only
- menuconfig MODULES
- bool "Enable loadable module support"
- modules
- select EXECMEM
- help
- Kernel modules are small pieces of compiled code which can
- be inserted in the running kernel, rather than being
- permanently built into the kernel. You use the "modprobe"
- tool to add (and sometimes remove) them. If you say Y here,
- many parts of the kernel can be built as modules (by
- answering M instead of Y where indicated): this is most
- useful for infrequently used options which are not required
- for booting. For more information, see the man pages for
- modprobe, lsmod, modinfo, insmod and rmmod.
- If you say Y here, you will need to run "make
- modules_install" to put the modules under /lib/modules/
- where modprobe can find them (you may need to be root to do
- this).
- If unsure, say Y.
- if MODULES
- config MODULE_DEBUGFS
- bool
- config MODULE_DEBUG
- bool "Module debugging"
- depends on DEBUG_FS
- help
- Allows you to enable / disable features which can help you debug
- modules. You don't need these options on production systems.
- if MODULE_DEBUG
- config MODULE_STATS
- bool "Module statistics"
- depends on DEBUG_FS
- select MODULE_DEBUGFS
- help
- This option allows you to maintain a record of module statistics.
- For example, size of all modules, average size, text size, a list
- of failed modules and the size for each of those. For failed
- modules we keep track of modules which failed due to either the
- existing module taking too long to load or that module was already
- loaded.
- You should enable this if you are debugging production loads
- and want to see if userspace or the kernel is doing stupid things
- with loading modules when it shouldn't or if you want to help
- optimize userspace / kernel space module autoloading schemes.
- You might want to do this because failed modules tend to use
- up significant amount of memory, and so you'd be doing everyone a
- favor in avoiding these failures proactively.
- This functionality is also useful for those experimenting with
- module .text ELF section optimization.
- If unsure, say N.
- config MODULE_DEBUG_AUTOLOAD_DUPS
- bool "Debug duplicate modules with auto-loading"
- help
- Module autoloading allows in-kernel code to request modules through
- the *request_module*() API calls. This in turn just calls userspace
- modprobe. Although modprobe checks to see if a module is already
- loaded before trying to load a module there is a small time window in
- which multiple duplicate requests can end up in userspace and multiple
- modprobe calls race calling finit_module() around the same time for
- duplicate modules. The finit_module() system call can consume in the
- worst case more than twice the respective module size in virtual
- memory for each duplicate module requests. Although duplicate module
- requests are non-fatal virtual memory is a limited resource and each
- duplicate module request ends up just unnecessarily straining virtual
- memory.
- This debugging facility will create pr_warn() splats for duplicate
- module requests to help identify if module auto-loading may be the
- culprit to your early boot virtual memory pressure. Since virtual
- memory abuse caused by duplicate module requests could render a
- system unusable this functionality will also converge races in
- requests for the same module to a single request. You can boot with
- the module.enable_dups_trace=1 kernel parameter to use WARN_ON()
- instead of the pr_warn().
- If the first module request used request_module_nowait() we cannot
- use that as the anchor to wait for duplicate module requests, since
- users of request_module() do want a proper return value. If a call
- for the same module happened earlier with request_module() though,
- then a duplicate request_module_nowait() would be detected. The
- non-wait request_module() call is synchronous and waits until modprobe
- completes. Subsequent auto-loading requests for the same module do
- not trigger a new finit_module() calls and do not strain virtual
- memory, and so as soon as modprobe successfully completes we remove
- tracking for duplicates for that module.
- Enable this functionality to try to debug virtual memory abuse during
- boot on systems which are failing to boot or if you suspect you may be
- straining virtual memory during boot, and you want to identify if the
- abuse was due to module auto-loading. These issues are currently only
- known to occur on systems with many CPUs (over 400) and is likely the
- result of udev issuing duplicate module requests for each CPU, and so
- module auto-loading is not the culprit. There may very well still be
- many duplicate module auto-loading requests which could be optimized
- for and this debugging facility can be used to help identify them.
- Only enable this for debugging system functionality, never have it
- enabled on real systems.
- config MODULE_DEBUG_AUTOLOAD_DUPS_TRACE
- bool "Force full stack trace when duplicates are found"
- depends on MODULE_DEBUG_AUTOLOAD_DUPS
- help
- Enabling this will force a full stack trace for duplicate module
- auto-loading requests using WARN_ON() instead of pr_warn(). You
- should keep this disabled at all times unless you are a developer
- and are doing a manual inspection and want to debug exactly why
- these duplicates occur.
- endif # MODULE_DEBUG
- config MODULE_FORCE_LOAD
- bool "Forced module loading"
- default n
- help
- Allow loading of modules without version information (ie. modprobe
- --force). Forced module loading sets the 'F' (forced) taint flag and
- is usually a really bad idea.
- config MODULE_UNLOAD
- bool "Module unloading"
- help
- Without this option you will not be able to unload any
- modules (note that some modules may not be unloadable
- anyway), which makes your kernel smaller, faster
- and simpler. If unsure, say Y.
- config MODULE_FORCE_UNLOAD
- bool "Forced module unloading"
- depends on MODULE_UNLOAD
- help
- This option allows you to force a module to unload, even if the
- kernel believes it is unsafe: the kernel will remove the module
- without waiting for anyone to stop using it (using the -f option to
- rmmod). This is mainly for kernel developers and desperate users.
- If unsure, say N.
- config MODULE_UNLOAD_TAINT_TRACKING
- bool "Tainted module unload tracking"
- depends on MODULE_UNLOAD
- select MODULE_DEBUGFS
- help
- This option allows you to maintain a record of each unloaded
- module that tainted the kernel. In addition to displaying a
- list of linked (or loaded) modules e.g. on detection of a bad
- page (see bad_page()), the aforementioned details are also
- shown. If unsure, say N.
- config MODVERSIONS
- bool "Module versioning support"
- depends on !COMPILE_TEST
- help
- Usually, you have to use modules compiled with your kernel.
- Saying Y here makes it sometimes possible to use modules
- compiled for different kernels, by adding enough information
- to the modules to (hopefully) spot any changes which would
- make them incompatible with the kernel you are running. If
- unsure, say N.
- config ASM_MODVERSIONS
- bool
- default HAVE_ASM_MODVERSIONS && MODVERSIONS
- help
- This enables module versioning for exported symbols also from
- assembly. This can be enabled only when the target architecture
- supports it.
- config MODULE_SRCVERSION_ALL
- bool "Source checksum for all modules"
- help
- Modules which contain a MODULE_VERSION get an extra "srcversion"
- field inserted into their modinfo section, which contains a
- sum of the source files which made it. This helps maintainers
- see exactly which source was used to build a module (since
- others sometimes change the module source without updating
- the version). With this option, such a "srcversion" field
- will be created for all modules. If unsure, say N.
- config MODULE_SIG
- bool "Module signature verification"
- select MODULE_SIG_FORMAT
- help
- Check modules for valid signatures upon load: the signature
- is simply appended to the module. For more information see
- <file:Documentation/admin-guide/module-signing.rst>.
- Note that this option adds the OpenSSL development packages as a
- kernel build dependency so that the signing tool can use its crypto
- library.
- You should enable this option if you wish to use either
- CONFIG_SECURITY_LOCKDOWN_LSM or lockdown functionality imposed via
- another LSM - otherwise unsigned modules will be loadable regardless
- of the lockdown policy.
- !!!WARNING!!! If you enable this option, you MUST make sure that the
- module DOES NOT get stripped after being signed. This includes the
- debuginfo strip done by some packagers (such as rpmbuild) and
- inclusion into an initramfs that wants the module size reduced.
- config MODULE_SIG_FORCE
- bool "Require modules to be validly signed"
- depends on MODULE_SIG
- help
- Reject unsigned modules or signed modules for which we don't have a
- key. Without this, such modules will simply taint the kernel.
- config MODULE_SIG_ALL
- bool "Automatically sign all modules"
- default y
- depends on MODULE_SIG || IMA_APPRAISE_MODSIG
- help
- Sign all modules during make modules_install. Without this option,
- modules must be signed manually, using the scripts/sign-file tool.
- comment "Do not forget to sign required modules with scripts/sign-file"
- depends on MODULE_SIG_FORCE && !MODULE_SIG_ALL
- choice
- prompt "Hash algorithm to sign modules"
- depends on MODULE_SIG || IMA_APPRAISE_MODSIG
- default MODULE_SIG_SHA512
- help
- This determines which sort of hashing algorithm will be used during
- signature generation. This algorithm _must_ be built into the kernel
- directly so that signature verification can take place. It is not
- possible to load a signed module containing the algorithm to check
- the signature on that module.
- config MODULE_SIG_SHA1
- bool "SHA-1"
- select CRYPTO_SHA1
- config MODULE_SIG_SHA256
- bool "SHA-256"
- select CRYPTO_SHA256
- config MODULE_SIG_SHA384
- bool "SHA-384"
- select CRYPTO_SHA512
- config MODULE_SIG_SHA512
- bool "SHA-512"
- select CRYPTO_SHA512
- config MODULE_SIG_SHA3_256
- bool "SHA3-256"
- select CRYPTO_SHA3
- config MODULE_SIG_SHA3_384
- bool "SHA3-384"
- select CRYPTO_SHA3
- config MODULE_SIG_SHA3_512
- bool "SHA3-512"
- select CRYPTO_SHA3
- endchoice
- config MODULE_SIG_HASH
- string
- depends on MODULE_SIG || IMA_APPRAISE_MODSIG
- default "sha1" if MODULE_SIG_SHA1
- default "sha256" if MODULE_SIG_SHA256
- default "sha384" if MODULE_SIG_SHA384
- default "sha512" if MODULE_SIG_SHA512
- default "sha3-256" if MODULE_SIG_SHA3_256
- default "sha3-384" if MODULE_SIG_SHA3_384
- default "sha3-512" if MODULE_SIG_SHA3_512
- config MODULE_COMPRESS
- bool "Module compression"
- help
- Enable module compression to reduce on-disk size of module binaries.
- This is fully compatible with signed modules.
- The tool used to work with modules needs to support the selected
- compression type. kmod MAY support gzip, xz and zstd. Other tools
- might have a limited selection of the supported types.
- Note that for modules inside an initrd or initramfs, it's more
- efficient to compress the whole ramdisk instead.
- If unsure, say N.
- choice
- prompt "Module compression type"
- depends on MODULE_COMPRESS
- help
- Choose the supported algorithm for module compression.
- config MODULE_COMPRESS_GZIP
- bool "GZIP"
- help
- Support modules compressed with GZIP. The installed modules are
- suffixed with .ko.gz.
- config MODULE_COMPRESS_XZ
- bool "XZ"
- help
- Support modules compressed with XZ. The installed modules are
- suffixed with .ko.xz.
- config MODULE_COMPRESS_ZSTD
- bool "ZSTD"
- help
- Support modules compressed with ZSTD. The installed modules are
- suffixed with .ko.zst.
- endchoice
- config MODULE_COMPRESS_ALL
- bool "Automatically compress all modules"
- default y
- depends on MODULE_COMPRESS
- help
- Compress all modules during 'make modules_install'.
- Your build system needs to provide the appropriate compression tool
- for the selected compression type. External modules will also be
- compressed in the same way during the installation.
- config MODULE_DECOMPRESS
- bool "Support in-kernel module decompression"
- depends on MODULE_COMPRESS
- select ZLIB_INFLATE if MODULE_COMPRESS_GZIP
- select XZ_DEC if MODULE_COMPRESS_XZ
- select ZSTD_DECOMPRESS if MODULE_COMPRESS_ZSTD
- help
- Support for decompressing kernel modules by the kernel itself
- instead of relying on userspace to perform this task. Useful when
- load pinning security policy is enabled.
- If unsure, say N.
- config MODULE_ALLOW_MISSING_NAMESPACE_IMPORTS
- bool "Allow loading of modules with missing namespace imports"
- help
- Symbols exported with EXPORT_SYMBOL_NS*() are considered exported in
- a namespace. A module that makes use of a symbol exported with such a
- namespace is required to import the namespace via MODULE_IMPORT_NS().
- There is no technical reason to enforce correct namespace imports,
- but it creates consistency between symbols defining namespaces and
- users importing namespaces they make use of. This option relaxes this
- requirement and lifts the enforcement when loading a module.
- If unsure, say N.
- config MODPROBE_PATH
- string "Path to modprobe binary"
- default "/sbin/modprobe"
- help
- When kernel code requests a module, it does so by calling
- the "modprobe" userspace utility. This option allows you to
- set the path where that binary is found. This can be changed
- at runtime via the sysctl file
- /proc/sys/kernel/modprobe. Setting this to the empty string
- removes the kernel's ability to request modules (but
- userspace can still load modules explicitly).
- config TRIM_UNUSED_KSYMS
- bool "Trim unused exported kernel symbols"
- help
- The kernel and some modules make many symbols available for
- other modules to use via EXPORT_SYMBOL() and variants. Depending
- on the set of modules being selected in your kernel configuration,
- many of those exported symbols might never be used.
- This option allows for unused exported symbols to be dropped from
- the build. In turn, this provides the compiler more opportunities
- (especially when using LTO) for optimizing the code and reducing
- binary size. This might have some security advantages as well.
- If unsure, or if you need to build out-of-tree modules, say N.
- config UNUSED_KSYMS_WHITELIST
- string "Whitelist of symbols to keep in ksymtab"
- depends on TRIM_UNUSED_KSYMS
- help
- By default, all unused exported symbols will be un-exported from the
- build when TRIM_UNUSED_KSYMS is selected.
- UNUSED_KSYMS_WHITELIST allows to whitelist symbols that must be kept
- exported at all times, even in absence of in-tree users. The value to
- set here is the path to a text file containing the list of symbols,
- one per line. The path can be absolute, or relative to the kernel
- source or obj tree.
- config MODULES_TREE_LOOKUP
- def_bool y
- depends on PERF_EVENTS || TRACING || CFI_CLANG
- endif # MODULES
|