mniip
no sys_call_table in /proc/kallsyms?
What kernel version are you using? Any particular config options that need to be on/off for sys_call_table to be present?
With kernel 4.9.60, I don't seem to have this symbol in kallsyms. While I have some things matching call.*table, they seem to be for sysctl or netfilter.
Nothing jumps out at me in my config options:
zcat /proc/config.gz | grep -i sym
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ABSOLUTE_PERCPU=y
CONFIG_KALLSYMS_BASE_RELATIVE=y
# CONFIG_TRIM_UNUSED_KSYMS is not set
# CONFIG_STRIP_ASM_SYMS is not set
# CONFIG_UNUSED_SYMBOLS is not set
Googling makes it sound like (years ago, at least) sys_call_table was hidden from kallsyms to make rootkits more difficult. It would be nice if this POC didn't require something that's typically hidden...
Even echo 0 > /proc/sys/kernel/kptr_restrict (as suggested in PR #1) doesn't help.
As root I get the table (Ubuntu, kernel 4.13), but with the hex value I get 'Invalid opcode' (transl.german 'Ungültiger Maschinenbefehl (Speicherabzug geschrieben)'). I tried it with -march=x86-64, =native, =core2, but no success.
@bsbhro Probably related to these:
"1: xorps %xmm0, %xmm0\n"
" aesimc %xmm0, %xmm0\n"
" aesimc %xmm0, %xmm0\n"
" aesimc %xmm0, %xmm0\n"
" aesimc %xmm0, %xmm0\n"
" movd %xmm0, %eax\n"
What model is your CPU exactly? I suppose I could achieve a similar effect with fdiv/idiv.
@mpictor Regarding the topic of this issue, the PoC demonstrates reading from a non-userspace-visible address. Finding that address out (it's protected by KASLR) is kind of out of the scope right now.
Maybe once I figure out the innards of the BPU and I get arbitrary data into L1 D$, and once I can read arbitrary kernel addresses I could come up with something that would defeat KASLR for you.
@mniip Are you planning on making that arbitrary loading into L1 public? That's what I'm struggling with now. I've tried various prefetching methods, both in ASM and C but no luck on arbitrary kernel space memory.
@Frichetten Assuming I figure it out. The plan is to poison the BPU to induce a branch mispredict in the kernel code that would cause a speculative memory fetch with the kernel's privileges. I'm assuming that even if the fetch isn't retired the L1D-TLB-L2 thing will load the line into L1D.
@mniip, I imagine that is how the Meltdown and Spectre research teams have done it. I'm excited for them to go public with POC code so I can get a look at it. As it stands I think you have the most complete public POC on the internet right now. Congrats to you.
@mniip
Finding that address out (it's protected by KASLR) is kind of out of the scope right now.
Until you have a way of finding the address, what about updating the README so that people don't waste a bunch of time trying to figure out why their system doesn't have the value you used?
Hi, thanks for your reply. I tried it on Notebooks with 'Intel(R) Core(TM)2 Duo CPU T5450 @ 1.66GHz', 'Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz', 'Intel(R) Core(TM) i3 CPU M 350 @ 2.27GHz'. Allways the same 'invalide opcode'. Is it possible to write such a proof universally?