Open mariusgrigaitis opened 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.
@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.
Actually i'm able to cat that file. I'm trying to run it inside docker container with full caps.
@mariusgrigaitis could you please inform what's the output of 'cat /proc/kallsyms | grep sys_call_table'?
root@e49629999042:/# cat /proc/kallsyms | grep sys_call_table
root@e49629999042:/#
@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.
@mariusgrigaitis ed5c4b20523fe6b27f66f26f3b0fd77f73c2fffc may help you. pull the latest changes and try again with root.
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.
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
@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.
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
root
access), orroot
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…?)
@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 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 EDIT2: actually it's only (null)
^ there is useless, so I had to use another symbol anyway;(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!):
Tried to run it:
Not sure what that means.