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讀取是否受到保護？

回答

相關問題