为何内核配置为"not set"的模块仍能成功加载？

问题场景 #

目标系统运行4.14.136版本内核，内核配置中并未开启multiport匹配支持：

$ zgrep MULTIPORT /proc/config.gz
# CONFIG_NETFILTER_XT_MATCH_MULTIPORT is not set

此时尝试添加iptables multiport规则失败，这符合预期：

$ iptables -A OUTPUT -o eth1 -p udp -m multiport --dports 1111,2222 -j LOG
iptables v1.8.2 (legacy): Couldn't load match `multiport':No such file or directory

随后在开发机上基于同版本内核源码，开启CONFIG_NETFILTER_XT_MATCH_MULTIPORT=m编译出xt_multiport.ko模块，将其复制到目标机后，未重启目标机（内核仍为未配置该选项的旧版本），直接加载模块成功：

$ zgrep MULTIPORT /proc/config.gz
# CONFIG_NETFILTER_XT_MATCH_MULTIPORT is not set
$ insmod /root/xt_multiport.ko
$ lsmod
Module                  Size  Used by
xt_multiport            4921  

加载完成后，之前失败的iptables规则可以正常添加，且符合条件的数据包能正确写入syslog，模块工作完全正常。

疑问：原本以为内核会拒绝加载这种在当前配置中标记为not set的模块，为什么实际能正常加载运行？

原因解析 #

1. 内核配置项是编译时开关，而非运行时校验规则
   CONFIG_NETFILTER_XT_MATCH_MULTIPORT这类配置项的作用仅仅是控制编译阶段是否将对应代码编译进内核或者编译为模块，它并不会作为运行时内核加载模块的强制校验条件。只要模块是基于同版本内核源码编译的，且目标内核支持模块加载（CONFIG_MODULES=y，这是绝大多数系统的默认配置），就可以正常加载。

2. netfilter扩展模块的独立性
   xt_multiport属于netfilter的独立扩展匹配模块，它只依赖内核中已存在的核心netfilter框架（4.14版本内核默认具备基础的netfilter支持）。当前内核配置里的# CONFIG_NETFILTER_XT_MATCH_MULTIPORT is not set，只是说明这个模块没有随内核一起编译，并不代表内核禁止加载外部编译的同版本模块。

3. 内核模块加载的核心校验逻辑
   内核加载模块时，只会重点校验以下内容：

• 模块的版本魔数（vermagic）与当前运行内核完全一致
• 模块依赖的核心符号（比如netfilter的基础函数）在当前内核中存在
• 模块的架构与目标系统匹配
  它不会去读取或校验当前内核的.config文件中的配置项，因为.config只是编译阶段的配置记录，运行时内核不会保存完整的配置状态来做这类校验。

简单来说：只要模块是同版本内核编译、依赖的核心功能齐全，哪怕当前内核没自带这个模块，手动加载后也能正常工作。

内容的提问来源于stack exchange，提问作者Tomiml