df3e764d8e
Loading modules with finit_module() can end up using vmalloc(), vmap()
and vmalloc() again, for a total of up to 3 separate allocations in the
worst case for a single module. We always kernel_read*() the module,
that's a vmalloc(). Then vmap() is used for the module decompression,
and if so the last read buffer is freed as we use the now decompressed
module buffer to stuff data into our copy module. The last allocation is
specific to each architectures but pretty much that's generally a series
of vmalloc() calls or a variation of vmalloc to handle ELF sections with
special permissions.
Evaluation with new stress-ng module support [1] with just 100 ops
is proving that you can end up using GiBs of data easily even with all
care we have in the kernel and userspace today in trying to not load modules
which are already loaded. 100 ops seems to resemble the sort of pressure a
system with about 400 CPUs can create on module loading. Although issues
relating to duplicate module requests due to each CPU inucurring a new
module reuest is silly and some of these are being fixed, we currently lack
proper tooling to help diagnose easily what happened, when it happened
and who likely is to blame -- userspace or kernel module autoloading.
Provide an initial set of stats which use debugfs to let us easily scrape
post-boot information about failed loads. This sort of information can
be used on production worklaods to try to optimize *avoiding* redundant
memory pressure using finit_module().
There's a few examples that can be provided:
A 255 vCPU system without the next patch in this series applied:
Startup finished in 19.143s (kernel) + 7.078s (userspace) = 26.221s
graphical.target reached after 6.988s in userspace
And 13.58 GiB of virtual memory space lost due to failed module loading:
root@big ~ # cat /sys/kernel/debug/modules/stats
Mods ever loaded 67
Mods failed on kread 0
Mods failed on decompress 0
Mods failed on becoming 0
Mods failed on load 1411
Total module size 11464704
Total mod text size 4194304
Failed kread bytes 0
Failed decompress bytes 0
Failed becoming bytes 0
Failed kmod bytes 14588526272
Virtual mem wasted bytes 14588526272
Average mod size 171115
Average mod text size 62602
Average fail load bytes 10339140
Duplicate failed modules:
module-name How-many-times Reason
kvm_intel 249 Load
kvm 249 Load
irqbypass 8 Load
crct10dif_pclmul 128 Load
ghash_clmulni_intel 27 Load
sha512_ssse3 50 Load
sha512_generic 200 Load
aesni_intel 249 Load
crypto_simd 41 Load
cryptd 131 Load
evdev 2 Load
serio_raw 1 Load
virtio_pci 3 Load
nvme 3 Load
nvme_core 3 Load
virtio_pci_legacy_dev 3 Load
virtio_pci_modern_dev 3 Load
t10_pi 3 Load
virtio 3 Load
crc32_pclmul 6 Load
crc64_rocksoft 3 Load
crc32c_intel 40 Load
virtio_ring 3 Load
crc64 3 Load
The following screen shot, of a simple 8vcpu 8 GiB KVM guest with the
next patch in this series applied, shows 226.53 MiB are wasted in virtual
memory allocations which due to duplicate module requests during boot.
It also shows an average module memory size of 167.10 KiB and an an
average module .text + .init.text size of 61.13 KiB. The end shows all
modules which were detected as duplicate requests and whether or not
they failed early after just the first kernel_read*() call or late after
we've already allocated the private space for the module in
layout_and_allocate(). A system with module decompression would reveal
more wasted virtual memory space.
We should put effort now into identifying the source of these duplicate
module requests and trimming these down as much possible. Larger systems
will obviously show much more wasted virtual memory allocations.
root@kmod ~ # cat /sys/kernel/debug/modules/stats
Mods ever loaded 67
Mods failed on kread 0
Mods failed on decompress 0
Mods failed on becoming 83
Mods failed on load 16
Total module size 11464704
Total mod text size 4194304
Failed kread bytes 0
Failed decompress bytes 0
Failed becoming bytes 228959096
Failed kmod bytes 8578080
Virtual mem wasted bytes 237537176
Average mod size 171115
Average mod text size 62602
Avg fail becoming bytes 2758544
Average fail load bytes 536130
Duplicate failed modules:
module-name How-many-times Reason
kvm_intel 7 Becoming
kvm 7 Becoming
irqbypass 6 Becoming & Load
crct10dif_pclmul 7 Becoming & Load
ghash_clmulni_intel 7 Becoming & Load
sha512_ssse3 6 Becoming & Load
sha512_generic 7 Becoming & Load
aesni_intel 7 Becoming
crypto_simd 7 Becoming & Load
cryptd 3 Becoming & Load
evdev 1 Becoming
serio_raw 1 Becoming
nvme 3 Becoming
nvme_core 3 Becoming
t10_pi 3 Becoming
virtio_pci 3 Becoming
crc32_pclmul 6 Becoming & Load
crc64_rocksoft 3 Becoming
crc32c_intel 3 Becoming
virtio_pci_modern_dev 2 Becoming
virtio_pci_legacy_dev 1 Becoming
crc64 2 Becoming
virtio 2 Becoming
virtio_ring 2 Becoming
[0] https://github.com/ColinIanKing/stress-ng.git
[1] echo 0 > /proc/sys/vm/oom_dump_tasks
./stress-ng --module 100 --module-name xfs
Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
334 lines
11 KiB
Plaintext
334 lines
11 KiB
Plaintext
# 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
|
|
|
|
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.
|
|
|
|
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"
|
|
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
|