Unable to find symbol sys_call_table in symbol map

[raphaelsc]

Unable to find symbol sys_call_table in symbol map

[mariusgrigaitis]

root@e49629999042:/# cat /proc/kallsyms | grep sys_call_table
root@e49629999042:/#

[raphaelsc]

@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]

@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]

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

[raphaelsc]

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

[raphaelsc]

@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]

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

[graphitemaster]

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]

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]

@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]

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]

@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

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 #2 (comment) and #2 (comment) 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: