4.8内核中sys_call_table读取是否受到保护？

我使用简单的sys_call_table重写为记录系统中的所有execve调用。4.8内核中sys_call_table读取是否受到保护？

当移动到Ubuntu 16.10与4.8内核中，这机制突然停止工作。在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

有谁知道发生了什么？也许一些保护机制已经推出？

来源

2016-10-17 Konrad Eisele

找到一个解决方案到目前为止：我重新编译4.8内核和导出符号sys_call_table的作为除去常量符以及。这样我可以直接从模块引用sys_call_table。尽管如此，为什么它会碰到4.6版本的版本呢？只读部分的链接是否更改？ –

您可以在[this]（https://outflux.net/slides/2016/lss/kspp.pdf）演示文稿中找到Linux已实施的所有缓解措施（最多可达4.2）的一个很好的总结。 –

谢谢。一个问题：如果kaslr存在，是否有办法让系统调用表地址返回？我想这会被认为是一个漏洞，但无论如何... –

似乎有成为地址空间布局随机化（kASLR）上的4.8内核正在发生默认情况下，系统调用表。当将sys_call_table符号声明为导出并直接从模块链接到sys_call_table符号时，sys_call_table的地址会针对每次引导进行更改。 /boot/System.map-xxx中的地址是无用的。

要在Ubuntu 16.10内核4.8一个禁用kaslr可以添加

nokaslr

到内核的命令行。

来源

2016-10-18 13:28:38

4.8内核中sys_call_table读取是否受到保护？

回答

相关问题