raphaelsc / Am-I-affected-by-Meltdown

Meltdown Exploit / Proof-of-concept / checks whether system is affected by Variant 3: rogue data cache load (CVE-2017-5754), a.k.a MELTDOWN.
https://meltdownattack.com/
BSD 2-Clause "Simplified" License
542 stars 71 forks source link

Unable to find symbol sys_call_table in symbol map #2

Open mariusgrigaitis opened 6 years ago

mariusgrigaitis commented 6 years ago

Tried to run it:

root@5b51e04d92df:/Am-I-affected-by-Meltdown# ./meltdown-checker
Unable to find symbol sys_call_table in symbol map. Aborting...Aborted

Not sure what that means.

raphaelsc commented 6 years ago

@mariusgrigaitis some systems don't allow a non-root program to read /proc/kallsyms, which meltdown-checker is built upon. Without it, we can't easily check if system is still affected by meltdown. Worth leaving this issue opened until we find another way of doing like running a process, creating a file with very specific data, make sure page cache has it cached, and then we'd search for that data in the kernel memory.

raphaelsc commented 6 years ago

@mariusgrigaitis i'll update the program to print an informative msg for this scenario. thanks for reporting it. i'll see what i can do to fix this issue.

mariusgrigaitis commented 6 years ago

Actually i'm able to cat that file. I'm trying to run it inside docker container with full caps.

raphaelsc commented 6 years ago

@mariusgrigaitis could you please inform what's the output of 'cat /proc/kallsyms | grep sys_call_table'?

mariusgrigaitis commented 6 years ago
root@e49629999042:/# cat /proc/kallsyms | grep sys_call_table
root@e49629999042:/#
raphaelsc commented 6 years ago

@mariusgrigaitis that's awkward, no sys_call_table. What's your kernel version? Could u pls try the same with /boot/System.map? If it does work on /boot/System.map, I'll make the checker fallback on it.

raphaelsc commented 6 years ago

@mariusgrigaitis ed5c4b20523fe6b27f66f26f3b0fd77f73c2fffc may help you. pull the latest changes and try again with root.

graphitemaster commented 6 years ago

I have the same problem, my /proc/kallsyms does not contain sys_call_table at all, running as root too

My kernel information is here:

[root@graphite-office Am-I-affected-by-Meltdown]# uname -a
Linux graphite-office 4.14.4-1-ARCH #1 SMP PREEMPT Tue Dec 5 19:10:06 UTC 2017 x86_64 GNU/Linux

There is also no /boot/*.map files either on this installation. I don't even have a typical /boot/ tho, since system is launched directly with EFIstub.

dlenski commented 6 years ago

On my stock Ubuntu 17.04 system, /proc/kallsyms shows all-zero addresses when read as non-root … while showing the real adresses when read as root:

$ cat /proc/kallsyms |grep sys_call_table
0000000000000000 R sys_call_table
0000000000000000 R ia32_sys_call_table

$ sudo cat /proc/kallsyms |grep sys_call_table
ffffffff81a00200 R sys_call_table
ffffffff81a01560 R ia32_sys_call_table

$ uname -srvmpio
Linux 4.4.0-102-generic #125-Ubuntu SMP Tue Nov 21 15:15:11 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
raphaelsc commented 6 years ago

@dlenski interesting. i added code for user to be aware of it here: https://github.com/raphaelsc/Am-I-affected-by-Meltdown/blob/master/meltdown_checker.cc#L172

I'm currently looking for alternatives to remove the need for root in such systems, like creating a process, make it cache very specific data, then look for that data in page cache.

dlenski commented 6 years ago

I'm currently looking for alternatives to remove the need for root in such systems, like creating a process, make it cache very specific data, then look for that data in page cache.

That's a pretty cool idea, although… I suspect that most of the users who are grateful for the tool you've created here are either

  1. Testing physical systems that they/own manage (so they have root access), or
  2. Testing cloud systems (so they have local root access but not hypervisor access)

So I'm thinking that the root requirement is not a big deal for many users. (Perhaps I'm overlooking a large contingient of PaaS users…?)

raphaelsc commented 6 years ago

@dlenski, @mariusgrigaitis, @graphitemaster: just added the below section to README that may be interesting to you all:

What to do when you face this error "Unable to read /proc/kallsyms..."

That's because your system may be preventing the program from reading kernel symbols in /proc/kallsyms due to /proc/sys/kernel/kptr_restrict set to 1. The following command will do the tricky:

sudo sh -c "echo 0  > /proc/sys/kernel/kptr_restrict"

Please tell me if it actually does the tricky

ghost commented 6 years ago

Required for sys_call_table to show up:

$ zcat /proc/config.gz |grep KALLSYMS_ALL
CONFIG_KALLSYMS_ALL=y

$ cat /proc/kallsyms | grep sys_call_table
          (null) R sys_call_table
          (null) R ia32_sys_call_table

(typically ArchLinux/Manjaro may have this off, a seen in https://github.com/raphaelsc/Am-I-affected-by-Meltdown/issues/2#issuecomment-355493547 and https://github.com/raphaelsc/Am-I-affected-by-Meltdown/issues/2#issuecomment-355585153 too)

EDIT: obviously the (null) ^ there is useless, so I had to use another symbol anyway; EDIT2: actually it's only (null) when reading as non-root!!!! I used another symbol because I didn't wanna recompile the kernel on that machine:

Alternatively, using symbol start_cpu0 instead of sys_call_table, this T400 is apparently not affected (ran it at least twice!):

console output ``` $ time ./meltdown-checker Checking whether system is affected by Variant 3: rogue data cache load (CVE-2017-5754), a.k.a MELTDOWN ... Checking syscall table (start_cpu0) found at address 0xffffffffa90002b0 ... so far so good (i.e. meltdown safe) ... so far so good (i.e. meltdown safe) ... so far so good (i.e. meltdown safe) ... so far so good (i.e. meltdown safe) ... so far so good (i.e. meltdown safe) ... so far so good (i.e. meltdown safe) ... so far so good (i.e. meltdown safe) ... so far so good (i.e. meltdown safe) ... so far so good (i.e. meltdown safe) ... so far so good (i.e. meltdown safe) ... System not affected (take it with a grain of salt though as false negative may be reported for specific environments; Please consider running it once again). real 0m38.547s user 0m37.460s sys 0m1.080s $ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 23 model name : Intel(R) Core(TM)2 Duo CPU T9400 @ 2.53GHz stepping : 6 microcode : 0x610 cpu MHz : 2534.000 cache size : 6144 KB physical id : 0 siblings : 2 core id : 0 cpu cores : 2 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl cpuid aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 lahf_lm tpr_shadow vnmi flexpriority dtherm bugs : bogomips : 5055.25 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: ```