Messages in this thread | | | From | Linus Torvalds <> | Date | Wed, 31 Aug 2016 10:15:19 -0700 | Subject | Re: [PATCH 3/6] x86/dumpstack: make printk_stack_address() more generally useful |
| |
On Wed, Aug 31, 2016 at 9:53 AM, Josh Poimboeuf <jpoimboe@redhat.com> wrote: > > Here's an example of what a stack dump looks like after this change:
Looks good, but it also shows:
> RSP: 0018:ffffc900008f3a68 EFLAGS: 00010246
Ok, we know the stack pointer now...
> RBP: ffffc900008f3a80 R08: 00000002a014a073 R09: ffffc900008f3aa0
.. and it looks like we have a frame pointer too, which is pretty close to the stack pointer. So let's look at the stack dump:
> Stack: > ffff880079af7350 ffff880079905400 0000000000000000 ffffc900008f3ae0 > ffffffffa0196610 0000000000000001 00010000ffffffff 0000000087654321
Yeah, counting down, the frame pointer points to the next frame, and right after that you see the return address: 0xffffffffa0196610.
So let's look at the call trace:
> Call Trace: > __send_control_msg+0x80/0xf0 [virtio_console]
Ok, so now we can match up that value to a symbol.
And that means that now we can match up *all* symbols in that module. Even if the module isn't readable on that machine, you can just look it up by checking the distro modules on another machine.
And if it had been core kernel code, you'd haev had the whole core kernel ofdfsets.
So I think the patch is good, and I think the oops looks great, but I think we should also just remove the stack dump. Sure, the register state *can* contain these things too, but almost never do (and didn't, in this example).
The stack dump actually goes back to forever, and it used to be useful back in 1992 or so. But it used to be useful mainly because stacks were simpler and we didn't have very good call traces anyway. I definitely remember having used them - I just do not remember having used them in the last ten+ years.
Of course, it's still true that if you can trigger an oops, you've likely already lost the security game, but since the stack dump is so useless, let's aim to just remove it and make games like the above harder.
I'm also sure that we probably have a lot of other addresses in dmesg that we should make sure aren't leaked. I did a quick grep and found
Base memory trampoline at [ffff8f5e00097000] 97000 size 24576 percpu: Embedded 35 pages/cpu @ffff8f6236c00000 s103640 r8192 d31528 u262144 Freeing SMP alternatives memory: 32K (ffffffffaaec1000 - ffffffffaaec9000)
and a few more, and didn't check if those might give load addresses away, but it would be good to check.
Linus
| |