no sys_call_table in /proc/kallsyms?

[mpictor]

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.

[ghost]

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.

[mniip]

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

[mniip]

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

(The innards of the BPU don't make a terrible lot of sense yet)

[Frichetten]

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

[mniip]

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

[Frichetten]

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

[mpictor]

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

[ghost]

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?