# SPDX-License-Identifier: GPL-2.0-onlymenuconfig 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"	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_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 config MODULE_SIG_SHA3_256	bool "Sign modules with SHA3-256"	select CRYPTO_SHA3 config MODULE_SIG_SHA3_384	bool "Sign modules with SHA3-384"	select CRYPTO_SHA3 config MODULE_SIG_SHA3_512	bool "Sign modules with 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 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"	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