好问题！这个点其实涉及Linux内核编译、内存布局设计的核心逻辑，我来一步步拆解：

核心原因：预编译内核的固定内存布局 #

绝大多数Linux发行版提供的是预编译的通用内核，而非针对每台机器单独编译。在编译内核时，链接器会使用固定的内存地址分配策略（比如关闭可重定位选项CONFIG_RELOCATABLE），将所有内核符号（包括sys_call_table）的地址提前写入ELF镜像的特定段中。

当内核被加载到内存时，会直接映射到编译时确定的固定地址区间——不管是重启同一台机器，还是把这个内核安装到同架构的其他机器上，加载后的内存映射逻辑完全一致，因此sys_call_table的地址自然保持恒定。

动态化的成本远高于收益 #

你提到的“动态化是否成本过高”确实是关键因素，同时还有技术兼容性的约束：

• 性能损耗不可接受：系统调用是用户态与内核态交互最频繁的路径，每秒可能触发数百万次。如果sys_call_table地址动态生成，每次系统调用都要额外执行地址查找逻辑，哪怕只是一次内存访问，累积的性能开销对系统整体响应速度的影响都非常显著。
• 内核内部兼容性风险：内核中有大量依赖固定内存地址的内部组件（比如调试工具、特定子系统的硬编码逻辑），如果动态化sys_call_table地址，这些组件需要全面适配，开发和维护成本极高。
• 安全收益有限：内核在2.4之后不导出sys_call_table符号，已经通过符号可见性限制增加了挂钩难度。即使地址固定，恶意代码想要挂钩系统调用，还需要绕过内核权限控制、页表保护等多层机制——动态化地址带来的安全提升，远不足以抵消性能和兼容性的损失。

补充：现代内核的KASLR例外 #

需要说明的是，现代Linux内核支持内核地址空间布局随机化（KASLR），开启后sys_call_table的地址会在每次重启时随机变化。但很多发行版默认关闭KASLR（或仅对非核心区域随机化），而且KASLR主要针对内核漏洞利用的缓解，并非为了动态化sys_call_table本身。

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