x86: Don't backtrace from trampoline asm
authorBarret Rhoden <brho@cs.berkeley.edu>
Thu, 28 Jul 2016 22:11:25 +0000 (18:11 -0400)
committerBarret Rhoden <brho@cs.berkeley.edu>
Fri, 29 Jul 2016 21:43:08 +0000 (17:43 -0400)
commit31f3a4156ea1b9e831463c1fceab5e5c7366892d
tree36ace0c2df1bde3635b6f1aedf5d377649778c9b
parent81c82b63870c1825b5a38b099e6090ce8c57bdc1
x86: Don't backtrace from trampoline asm

Imagine this.  Userspace happens to load %rbp with a value that the kernel
cannot dereference.  Then it enters the kernel.  In the brief period before
the kernel sets rbp = 0 and starts its day, a profiling NMI arrives.  The
backtrace would flip out.

We could use something like a safe copy_from sort of call (copy_from_user()
won't work as is, incidentally, since it has built-in checks for user
addresses).  However, even if we set the address correctly, the user just
gained the ability to read kernel memory.  Set rbp, then do a bunch of null
syscalls in a loop with perf running.  Eventually you'll hit the bug.
Yeah, that's really rare.  Luckily, this did not come up - I just noticed
it in passing.

The nice thing about this approach is that the kernel should not be
backtracing beyond its entry point, regardless of the value of rbp.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
kern/arch/x86/kdebug.c
kern/arch/x86/process64.c
kern/arch/x86/trapentry64.S