2023-08-30 17:31:07 +02:00
|
|
|
# SPDX-License-Identifier: GPL-2.0-only
|
|
|
|
|
menuconfig MODULES
|
|
|
|
|
bool "Enable loadable module support"
|
|
|
|
|
modules
|
|
|
|
|
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
|
|
|
|
|
|
2023-10-24 12:59:35 +02:00
|
|
|
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
|
|
|
|
|
|
2023-08-30 17:31:07 +02:00
|
|
|
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
|
2023-10-24 12:59:35 +02:00
|
|
|
select MODULE_DEBUGFS
|
2023-08-30 17:31:07 +02:00
|
|
|
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"
|
|
|
|
|
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 "Which hash algorithm should modules be signed with?"
|
|
|
|
|
depends on MODULE_SIG || IMA_APPRAISE_MODSIG
|
|
|
|
|
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 "Sign modules with SHA-1"
|
|
|
|
|
select CRYPTO_SHA1
|
|
|
|
|
|
|
|
|
|
config MODULE_SIG_SHA224
|
|
|
|
|
bool "Sign modules with SHA-224"
|
|
|
|
|
select CRYPTO_SHA256
|
|
|
|
|
|
|
|
|
|
config MODULE_SIG_SHA256
|
|
|
|
|
bool "Sign modules with SHA-256"
|
|
|
|
|
select CRYPTO_SHA256
|
|
|
|
|
|
|
|
|
|
config MODULE_SIG_SHA384
|
|
|
|
|
bool "Sign modules with SHA-384"
|
|
|
|
|
select CRYPTO_SHA512
|
|
|
|
|
|
|
|
|
|
config MODULE_SIG_SHA512
|
|
|
|
|
bool "Sign modules with SHA-512"
|
|
|
|
|
select CRYPTO_SHA512
|
|
|
|
|
|
|
|
|
|
endchoice
|
|
|
|
|
|
|
|
|
|
config MODULE_SIG_HASH
|
|
|
|
|
string
|
|
|
|
|
depends on MODULE_SIG || IMA_APPRAISE_MODSIG
|
|
|
|
|
default "sha1" if MODULE_SIG_SHA1
|
|
|
|
|
default "sha224" if MODULE_SIG_SHA224
|
|
|
|
|
default "sha256" if MODULE_SIG_SHA256
|
|
|
|
|
default "sha384" if MODULE_SIG_SHA384
|
|
|
|
|
default "sha512" if MODULE_SIG_SHA512
|
|
|
|
|
|
|
|
|
|
choice
|
|
|
|
|
prompt "Module compression mode"
|
|
|
|
|
help
|
|
|
|
|
This option allows you to choose the algorithm which will be used to
|
|
|
|
|
compress modules when 'make modules_install' is run. (or, you can
|
|
|
|
|
choose to not compress modules at all.)
|
|
|
|
|
|
|
|
|
|
External modules will also be compressed in the same way during the
|
|
|
|
|
installation.
|
|
|
|
|
|
|
|
|
|
For modules inside an initrd or initramfs, it's more efficient to
|
|
|
|
|
compress the whole initrd or initramfs instead.
|
|
|
|
|
|
|
|
|
|
This is fully compatible with signed modules.
|
|
|
|
|
|
|
|
|
|
Please note that the tool used to load modules needs to support the
|
|
|
|
|
corresponding algorithm. module-init-tools MAY support gzip, and kmod
|
|
|
|
|
MAY support gzip, xz and zstd.
|
|
|
|
|
|
|
|
|
|
Your build system needs to provide the appropriate compression tool
|
|
|
|
|
to compress the modules.
|
|
|
|
|
|
|
|
|
|
If in doubt, select 'None'.
|
|
|
|
|
|
|
|
|
|
config MODULE_COMPRESS_NONE
|
|
|
|
|
bool "None"
|
|
|
|
|
help
|
|
|
|
|
Do not compress modules. The installed modules are suffixed
|
|
|
|
|
with .ko.
|
|
|
|
|
|
|
|
|
|
config MODULE_COMPRESS_GZIP
|
|
|
|
|
bool "GZIP"
|
|
|
|
|
help
|
|
|
|
|
Compress modules with GZIP. The installed modules are suffixed
|
|
|
|
|
with .ko.gz.
|
|
|
|
|
|
|
|
|
|
config MODULE_COMPRESS_XZ
|
|
|
|
|
bool "XZ"
|
|
|
|
|
help
|
|
|
|
|
Compress modules with XZ. The installed modules are suffixed
|
|
|
|
|
with .ko.xz.
|
|
|
|
|
|
|
|
|
|
config MODULE_COMPRESS_ZSTD
|
|
|
|
|
bool "ZSTD"
|
|
|
|
|
help
|
|
|
|
|
Compress modules with ZSTD. The installed modules are suffixed
|
|
|
|
|
with .ko.zst.
|
|
|
|
|
|
|
|
|
|
endchoice
|
|
|
|
|
|
|
|
|
|
config MODULE_DECOMPRESS
|
|
|
|
|
bool "Support in-kernel module decompression"
|
|
|
|
|
depends on MODULE_COMPRESS_GZIP || MODULE_COMPRESS_XZ || MODULE_COMPRESS_ZSTD
|
|
|
|
|
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" if EXPERT
|
|
|
|
|
depends on !COMPILE_TEST
|
|
|
|
|
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 tree.
|
|
|
|
|
|
|
|
|
|
config MODULES_TREE_LOOKUP
|
|
|
|
|
def_bool y
|
|
|
|
|
depends on PERF_EVENTS || TRACING || CFI_CLANG
|
|
|
|
|
|
|
|
|
|
endif # MODULES
|
