4.8 内核中的 sys_call_table 读保护吗？答案

【问题标题】：Is the sys_call_table read protected in 4.8 kernel?4.8 内核中的 sys_call_table 读保护吗？
【发布时间】：2016-10-17 07:36:14
【问题描述】：

我使用简单的 sys_call_table 重写记录系统中的所有 execve 调用。

当迁移到带有 4.8 内核的 Ubuntu 16.10 时，机制突然停止工作。在 16.04 与它正在运行的 4.6 内核。

    1: write_cr0 (read_cr0 () & (~ 0x10000));

    2: original_execve = (void *)syscall_table[__NR_execve];
    3: syscall_table[__NR_execve] = (unsigned long)&new_execve;

    4: write_cr0 (read_cr0 () | 0x10000);

读取旧条目时已经发生页面错误，即第 2 行。要检索我使用的 sys_call_table 地址：

sudo cat /boot/System.map-`uname -r` | grep -e '\ssys_call_table' | awk '{ print $1}' )"

代码来自：https://github.com/eiselekd/shinterposer/tree/master/mod

有谁知道发生了什么？也许有些是否引入了保护机制？

【问题讨论】：

到目前为止找到了一个解决方案：我重新编译了 4.8 内核并导出了符号 sys_call_table 并删除了 const 说明符。这样我就可以直接从模块中引用 sys_call_table 。仍然不确定为什么它与适用于 4.6 的版本崩溃。只读部分的链接是否更改？
您可以在this 演示文稿中找到对 Linux 已实施的所有缓解措施（无论如何最高 4.2）的一个很好的总结。
谢谢。一个问题：如果 kaslr 存在，有没有办法真正取回系统调用表地址？我想这会被认为是一种利用，但无论如何......

标签： linux-kernel system-calls

【解决方案1】：

系统调用表上似乎有 Address Space Layout Randomization (kASLR) 默认放置在 4.8 内核中。当将 sys_call_table 符号声明为已导出并直接从模块链接到它时，sys_call_table 的地址在每次启动时都会发生变化。 /boot/System.map-xxx 的地址没用。

要在 ubuntu 16.10 内核 4.8 中禁用 kaslr，可以添加

nokaslr

到内核命令行。

【讨论】：