为什么sys_call_table的地址不能用System.map中的system_wq的地址推导出来？

Question

在尝试推导关于此主题的上的 KASLR 偏移偏移的建议解决方案后，我意识到 system_wq 的运行时间地址与 [= 中的不同19=] KASLR 是否启用（尽管它在不同的 KASLR 禁用引导之间保持相同，这显然不会发生在相反的情况下）。

以下代码段应使用 system_wq 的运行时间地址以及 system_wq 和 [=] 的 System.map 地址计算 sys_call_table 地址20=]（假设 sysmap_* 包含对应的 System.map 地址）。 dmesg 输出在代码段下方。

runtime_sys_call_table = (unsigned long *)
((unsigned long)system_wq - (sysmap_system_wq - sysmap_sys_call_table));

printk("System.map system_wq:             0x%lx\n", sysmap_system_wq);
printk("System.map sys_call_table:        0x%lx\n", sysmap_sys_call_table);
printk("Run time system_wq:               0x%lx\n", (unsigned long)system_wq);
printk("Expected run time sys_call_table: 0x%lx\n", (unsigned long)runtime_sys_call_table);

启用 KASLR

引导 1:

[  126.922753] [lkm] lkm_init: System.map system_wq:             0xffffffff821204b8
[  127.230661] [lkm] lkm_init: System.map sys_call_table:        0xffffffff81c002a0
[  127.230662] [lkm] lkm_init: Run time system_wq:               0xffff91fcbe40ae00
[  127.230662] [lkm] lkm_init: Expected run time sys_call_table: 0xffff91fcbdeeabe8

引导 2:

[  140.689652] [lkm] lkm_init: System.map system_wq:             0xffffffff821204b8
[  140.993379] [lkm] lkm_init: System.map sys_call_table:        0xffffffff81c002a0
[  140.993381] [lkm] lkm_init: Run time system_wq:               0xffff9a69be40ae00
[  140.993382] [lkm] lkm_init: Expected run time sys_call_table: 0xffff9a69bdeeabe8

KASLR 已禁用

引导 1:

[  143.699539] [lkm] lkm_init: System.map system_wq:             0xffffffff821204b8
[  144.002094] [lkm] lkm_init: System.map sys_call_table:        0xffffffff81c002a0
[  144.002095] [lkm] lkm_init: Run time system_wq:               0xffff88803e40ae00
[  144.002096] [lkm] lkm_init: Expected run time sys_call_table: 0xffff88803deeabe8

引导 2:

[  133.828917] [lkm] lkm_init: System.map system_wq:             0xffffffff821204b8
[  134.132394] [lkm] lkm_init: System.map sys_call_table:        0xffffffff81c002a0
[  134.132395] [lkm] lkm_init: Run time system_wq:               0xffff88803e40ae00
[  134.132395] [lkm] lkm_init: Expected run time sys_call_table: 0xffff88803deeabe8

问题

1。为什么 sys_call_table 的运行时间地址与 System.map 的时间地址相匹配（我知道这是因为系统调用已成功挂钩）当 KASLR 被禁用而 system_wq 的时间地址却没有？

2。为什么代码段无法计算 sys_call_table 的运行时间地址，无论 KASLR 是否启用？

3。如果是system_wq的运行时间地址无论如何都会和System.map不一样，那还有什么导出的符号可以用来推导sys_call_table？

Answer 1

Ian Abbott 的评论解决了我的问题并使所有问题都过时了。为了澄清，我的困惑是 system_wq 是指向 struct workqueue_struct 的简单指针，这让我认为它已经包含了我想要的地址；然后我想我只需要像使用 sys_call_table 那样转换它，它实际上是一个指针数组，使 (unsigned long)sys_call_table 成为 sys_call_table 的正确地址，而 (unsigned long)&system_wq 将是system_wq.

为什么sys_call_table的地址不能用System.map中的system_wq的地址推导出来？

Why can't the address of sys_call_table be derived using that of system_wq in System.map?

c

rootkit

system-calls

kernel-module

linux-kernel

启用 KASLR

KASLR 已禁用

问题