mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson
synced 2025-08-27 06:50:37 +00:00
9520a2b3f0
With CONFIG_GENDWARFKSYMS, __gendwarfksyms_ptr variables are
added to the kernel in EXPORT_SYMBOL() to ensure DWARF type
information is available for exported symbols in the TUs where
they're actually exported. These symbols are dropped when linking
vmlinux, but dangling references to them remain in DWARF.
With CONFIG_DEBUG_INFO_BTF enabled on X86, pahole versions after
commit 47dcb534e253 ("btf_encoder: Stop indexing symbols for
VARs") and before commit 9810758003ce ("btf_encoder: Verify 0
address DWARF variables are in ELF section") place these symbols
in the .data..percpu section, which results in an "Invalid
offset" error in btf_datasec_check_meta() during boot, as all
the variables are at zero offset and have non-zero size. If
CONFIG_DEBUG_INFO_BTF_MODULES is enabled, this also results in a
failure to load modules with:
failed to validate module [$module] BTF: -22
As the issue occurs in pahole v1.28 and the fix was merged
after v1.29 was released, require pahole <v1.28 or >v1.29 when
GENDWARFKSYMS is enabled with DEBUG_INFO_BTF on X86.
Reported-by: Paolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
466 lines
16 KiB
Plaintext
466 lines
16 KiB
Plaintext
# 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.
|
|
|
|
choice
|
|
prompt "Module versioning implementation"
|
|
depends on MODVERSIONS
|
|
help
|
|
Select the tool used to calculate symbol versions for modules.
|
|
|
|
If unsure, select GENKSYMS.
|
|
|
|
config GENKSYMS
|
|
bool "genksyms (from source code)"
|
|
help
|
|
Calculate symbol versions from pre-processed source code using
|
|
genksyms.
|
|
|
|
If unsure, say Y.
|
|
|
|
config GENDWARFKSYMS
|
|
bool "gendwarfksyms (from debugging information)"
|
|
depends on DEBUG_INFO
|
|
# Requires full debugging information, split DWARF not supported.
|
|
depends on !DEBUG_INFO_REDUCED && !DEBUG_INFO_SPLIT
|
|
# Requires ELF object files.
|
|
depends on !LTO
|
|
# To avoid conflicts with the discarded __gendwarfksyms_ptr symbols on
|
|
# X86, requires pahole before commit 47dcb534e253 ("btf_encoder: Stop
|
|
# indexing symbols for VARs") or after commit 9810758003ce ("btf_encoder:
|
|
# Verify 0 address DWARF variables are in ELF section").
|
|
depends on !X86 || !DEBUG_INFO_BTF || PAHOLE_VERSION < 128 || PAHOLE_VERSION > 129
|
|
help
|
|
Calculate symbol versions from DWARF debugging information using
|
|
gendwarfksyms. Requires DEBUG_INFO to be enabled.
|
|
|
|
If unsure, say N.
|
|
endchoice
|
|
|
|
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 EXTENDED_MODVERSIONS
|
|
bool "Extended Module Versioning Support"
|
|
depends on MODVERSIONS
|
|
help
|
|
This enables extended MODVERSIONs support, allowing long symbol
|
|
names to be versioned.
|
|
|
|
The most likely reason you would enable this is to enable Rust
|
|
support. If unsure, say N.
|
|
|
|
config BASIC_MODVERSIONS
|
|
bool "Basic Module Versioning Support"
|
|
depends on MODVERSIONS
|
|
default y
|
|
help
|
|
This enables basic MODVERSIONS support, allowing older tools or
|
|
kernels to potentially load modules.
|
|
|
|
Disabling this may cause older `modprobe` or `kmod` to be unable
|
|
to read MODVERSIONS information from built modules. With this
|
|
disabled, older kernels may treat this module as unversioned.
|
|
|
|
This is enabled by default when MODVERSIONS are enabled.
|
|
If unsure, say Y.
|
|
|
|
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
|