This moves all the module symbols from init/Kconfig to its
own dedicated file now that we have all of the module code in
its own directory.
This does not introduce any functional changes.
Signed-off-by: Luis Chamberlain <[email protected]>
---
init/Kconfig | 298 +-----------------------------------------
kernel/module/Kconfig | 296 +++++++++++++++++++++++++++++++++++++++++
2 files changed, 297 insertions(+), 297 deletions(-)
create mode 100644 kernel/module/Kconfig
diff --git a/init/Kconfig b/init/Kconfig
index c7900e8975f1..afb45347b775 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1918,303 +1918,6 @@ config BASE_SMALL
default 0 if BASE_FULL
default 1 if !BASE_FULL
-config MODULE_SIG_FORMAT
- def_bool n
- select SYSTEM_DATA_VERIFICATION
-
-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_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
- default n
- 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
- select ZLIB_INFLATE if MODULE_COMPRESS_GZIP
- select XZ_DEC if MODULE_COMPRESS_XZ
- 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.
-
-endif # MODULES
-
-config MODULES_TREE_LOOKUP
- def_bool y
- depends on PERF_EVENTS || TRACING || CFI_CLANG
-
config INIT_ALL_POSSIBLE
bool
help
@@ -2224,6 +1927,7 @@ config INIT_ALL_POSSIBLE
it was better to provide this option than to break all the archs
and have several arch maintainers pursuing me down dark alleys.
+source "kernel/module/Kconfig"
source "block/Kconfig"
config PREEMPT_NOTIFIERS
diff --git a/kernel/module/Kconfig b/kernel/module/Kconfig
new file mode 100644
index 000000000000..5aff8a40c58e
--- /dev/null
+++ b/kernel/module/Kconfig
@@ -0,0 +1,296 @@
+config MODULE_SIG_FORMAT
+ def_bool n
+ select SYSTEM_DATA_VERIFICATION
+
+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_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
+ default n
+ 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
+ select ZLIB_INFLATE if MODULE_COMPRESS_GZIP
+ select XZ_DEC if MODULE_COMPRESS_XZ
+ 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.
+
+endif # MODULES
+
+config MODULES_TREE_LOOKUP
+ def_bool y
+ depends on PERF_EVENTS || TRACING || CFI_CLANG
--
2.35.1
Le 11/07/2022 à 18:20, Luis Chamberlain a écrit :
> This moves all the module symbols from init/Kconfig to its
> own dedicated file now that we have all of the module code in
> its own directory.
>
> This does not introduce any functional changes.
>
> Signed-off-by: Luis Chamberlain <[email protected]>
It is similar to the patch I sent in February, isn't it ?
(https://patchwork.kernel.org/project/linux-modules/patch/4042712961d42186c449734c253511ea7076c780.1645543105.git.christophe.leroy@csgroup.eu/)
> ---
> init/Kconfig | 298 +-----------------------------------------
> kernel/module/Kconfig | 296 +++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 297 insertions(+), 297 deletions(-)
> create mode 100644 kernel/module/Kconfig
>
> diff --git a/init/Kconfig b/init/Kconfig
> index c7900e8975f1..afb45347b775 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -1918,303 +1918,6 @@ config BASE_SMALL
> default 0 if BASE_FULL
> default 1 if !BASE_FULL
>
> -config MODULE_SIG_FORMAT
> - def_bool n
> - select SYSTEM_DATA_VERIFICATION
> -
MODULE_SIG_FORMAT is not used in kernel/module/Makefile but still in
kernel/Makefile, that's the reason why in my patch I left it in init/Kconfig
Christophe
> -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_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
> - default n
> - 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
> - select ZLIB_INFLATE if MODULE_COMPRESS_GZIP
> - select XZ_DEC if MODULE_COMPRESS_XZ
> - 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.
> -
> -endif # MODULES
> -
> -config MODULES_TREE_LOOKUP
> - def_bool y
> - depends on PERF_EVENTS || TRACING || CFI_CLANG
> -
> config INIT_ALL_POSSIBLE
> bool
> help
> @@ -2224,6 +1927,7 @@ config INIT_ALL_POSSIBLE
> it was better to provide this option than to break all the archs
> and have several arch maintainers pursuing me down dark alleys.
>
> +source "kernel/module/Kconfig"
> source "block/Kconfig"
>
> config PREEMPT_NOTIFIERS
> diff --git a/kernel/module/Kconfig b/kernel/module/Kconfig
> new file mode 100644
> index 000000000000..5aff8a40c58e
> --- /dev/null
> +++ b/kernel/module/Kconfig
> @@ -0,0 +1,296 @@
> +config MODULE_SIG_FORMAT
> + def_bool n
> + select SYSTEM_DATA_VERIFICATION
> +
> +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_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
> + default n
> + 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
> + select ZLIB_INFLATE if MODULE_COMPRESS_GZIP
> + select XZ_DEC if MODULE_COMPRESS_XZ
> + 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.
> +
> +endif # MODULES
> +
> +config MODULES_TREE_LOOKUP
> + def_bool y
> + depends on PERF_EVENTS || TRACING || CFI_CLANG
On Mon, Jul 11, 2022 at 06:33:08PM +0000, Christophe Leroy wrote:
>
>
> Le 11/07/2022 ? 18:20, Luis Chamberlain a ?crit?:
> > This moves all the module symbols from init/Kconfig to its
> > own dedicated file now that we have all of the module code in
> > its own directory.
> >
> > This does not introduce any functional changes.
> >
> > Signed-off-by: Luis Chamberlain <[email protected]>
>
> It is similar to the patch I sent in February, isn't it ?
> (https://patchwork.kernel.org/project/linux-modules/patch/4042712961d42186c449734c253511ea7076c780.1645543105.git.christophe.leroy@csgroup.eu/)
Sorry, I had missed that. Can you send a new v2 based on today's
modules-next? And I'll just drop my patch?
Luis
Le 11/07/2022 à 21:07, Luis Chamberlain a écrit :
> On Mon, Jul 11, 2022 at 06:33:08PM +0000, Christophe Leroy wrote:
>>
>>
>> Le 11/07/2022 à 18:20, Luis Chamberlain a écrit :
>>> This moves all the module symbols from init/Kconfig to its
>>> own dedicated file now that we have all of the module code in
>>> its own directory.
>>>
>>> This does not introduce any functional changes.
>>>
>>> Signed-off-by: Luis Chamberlain <[email protected]>
>>
>> It is similar to the patch I sent in February, isn't it ?
>> (https://patchwork.kernel.org/project/linux-modules/patch/4042712961d42186c449734c253511ea7076c780.1645543105.git.christophe.leroy@csgroup.eu/)
>
> Sorry, I had missed that. Can you send a new v2 based on today's
> modules-next? And I'll just drop my patch?
>
I sent out v2 rebased on today's modules-next
(c76654e22da1e0cb830bd0eb5832072fb76df358)
I see all my patches still have status 'new' in modules's patchwork
(https://patchwork.kernel.org/project/linux-modules/list/?submitter=192363).
Don't you maintain it ?
Thanks
Christophe
On Tue, Jul 12, 2022 at 05:57:35AM +0000, Christophe Leroy wrote:
>
>
> Le 11/07/2022 ? 21:07, Luis Chamberlain a ?crit?:
> > On Mon, Jul 11, 2022 at 06:33:08PM +0000, Christophe Leroy wrote:
> >>
> >>
> >> Le 11/07/2022 ? 18:20, Luis Chamberlain a ?crit?:
> >>> This moves all the module symbols from init/Kconfig to its
> >>> own dedicated file now that we have all of the module code in
> >>> its own directory.
> >>>
> >>> This does not introduce any functional changes.
> >>>
> >>> Signed-off-by: Luis Chamberlain <[email protected]>
> >>
> >> It is similar to the patch I sent in February, isn't it ?
> >> (https://patchwork.kernel.org/project/linux-modules/patch/4042712961d42186c449734c253511ea7076c780.1645543105.git.christophe.leroy@csgroup.eu/)
> >
> > Sorry, I had missed that. Can you send a new v2 based on today's
> > modules-next? And I'll just drop my patch?
> >
>
> I sent out v2 rebased on today's modules-next
> (c76654e22da1e0cb830bd0eb5832072fb76df358)
>
> I see all my patches still have status 'new' in modules's patchwork
> (https://patchwork.kernel.org/project/linux-modules/list/?submitter=192363).
>
> Don't you maintain it ?
Yes but I never knew we used to have patchwork for modules, but glad we have
that now. Anyway all your patches are applied, is patchwork dumb to not
pick that up?
Luis
Luis Chamberlain <[email protected]> writes:
> On Tue, Jul 12, 2022 at 05:57:35AM +0000, Christophe Leroy wrote:
>>
>>
>> Le 11/07/2022 à 21:07, Luis Chamberlain a écrit :
>> > On Mon, Jul 11, 2022 at 06:33:08PM +0000, Christophe Leroy wrote:
>> >>
>> >>
>> >> Le 11/07/2022 à 18:20, Luis Chamberlain a écrit :
>> >>> This moves all the module symbols from init/Kconfig to its
>> >>> own dedicated file now that we have all of the module code in
>> >>> its own directory.
>> >>>
>> >>> This does not introduce any functional changes.
>> >>>
>> >>> Signed-off-by: Luis Chamberlain <[email protected]>
>> >>
>> >> It is similar to the patch I sent in February, isn't it ?
>> >> (https://patchwork.kernel.org/project/linux-modules/patch/4042712961d42186c449734c253511ea7076c780.1645543105.git.christophe.leroy@csgroup.eu/)
>> >
>> > Sorry, I had missed that. Can you send a new v2 based on today's
>> > modules-next? And I'll just drop my patch?
>> >
>>
>> I sent out v2 rebased on today's modules-next
>> (c76654e22da1e0cb830bd0eb5832072fb76df358)
>>
>> I see all my patches still have status 'new' in modules's patchwork
>> (https://patchwork.kernel.org/project/linux-modules/list/?submitter=192363).
>>
>> Don't you maintain it ?
>
> Yes but I never knew we used to have patchwork for modules, but glad we have
> that now. Anyway all your patches are applied, is patchwork dumb to not
> pick that up?
patchwork does not have that functionality built in, you need to enable
the bot separately:
https://korg.docs.kernel.org/patchwork/pwbot.html
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches