2

Consider the output of /boot/System.map-5.8.0-50-generic and /proc/kallsyms on Ubuntu 20.10 (Groovy Gorilla):

$ sudo cat /boot/System.map-5.8.0-50-generic | grep sys_call_table
ffffffff820002e0 D sys_call_table
ffffffff82001360 D ia32_sys_call_table
ffffffff82002120 D x32_sys_call_table
$ sudo cat /proc/kallsyms | grep sys_call_table
ffffffff978002e0 D sys_call_table
ffffffff97801360 D ia32_sys_call_table
ffffffff97802120 D x32_sys_call_table

AFAIK, these files should contain the current load addresses of kernel symbols, so why don't they match?

Is it because only /proc/kallsyms is affected by KASLR? If so, how can I verify whether KASLR is enabled?

Shuzheng
  • 4,023
  • 1
  • 31
  • 71

1 Answers1

2

Yes, this is caused by KASLR. Note that all addresses are offset by the same amount. The kernel doesn’t know about System.map so it doesn’t update it.

I’m not aware of any way of detecting whether KASLR is enabled from userspace at runtime, short of comparing /proc/kallsyms and System.map, or possibly causing a panic on x86 (the kernel dumps its offset on panic there).

Stephen Kitt
  • 411,918
  • 54
  • 1,065
  • 1,164
  • 1
    Panics are fatal. `System.map` contains the symbol addresses as determined by `nm` from the kernel image; without KASLR they do end up being the addresses in virtual memory, yes. – Stephen Kitt May 04 '21 at 13:12
  • Sorry, yes, “fatal” means the system is no longer usable (and [Linux can be configured to reboot automatically after a panic](https://unix.stackexchange.com/a/564749/86440)), so leaking the offset doesn’t reduce the system’s security. – Stephen Kitt May 04 '21 at 13:38
  • The kernel does operate in a virtual address space... – Stephen Kitt May 04 '21 at 14:42
  • Yes, you are right. Sorry, I was confused. Thought for a second the kernel only utilizes virtual memory spaces for user-space processes. – Shuzheng May 05 '21 at 07:27