Skip to content
  • Josh Poimboeuf's avatar
    x86/dumpstack: Remove kernel text addresses from stack dump · bb5e5ce5
    Josh Poimboeuf authored and Ingo Molnar's avatar Ingo Molnar committed
    Printing kernel text addresses in stack dumps is of questionable value,
    especially now that address randomization is becoming common.
    
    It can be a security issue because it leaks kernel addresses.  It also
    affects the usefulness of the stack dump.  Linus says:
    
      "I actually spend time cleaning up commit messages in logs, because
      useless data that isn't actually information (random hex numbers) is
      actively detrimental.
    
      It makes commit logs less legible.
    
      It also makes it harder to parse dumps.
    
      It's not useful. That makes it actively bad.
    
      I probably look at more oops reports than most people. I have not
      found the hex numbers useful for the last five years, because they are
      just randomized crap.
    
      The stack content thing just makes code scroll off the screen etc, for
      example."
    
    The only real downside to removing these addresses is that they can be
    used to disambiguate duplicate symbol names.  However such cases are
    rare, and the context of the stack dump should be enough to be able to
    figure it out.
    
    There's now a 'faddr2line' script which can be used to convert a
    function address to a file name and line:
    
      $ ./scripts/faddr2line ~/k/vmlinux write_sysrq_trigger+0x51/0x60
      write_sysrq_trigger+0x51/0x60:
      write_sysrq_trigger at drivers/tty/sysrq.c:1098
    
    Or gdb can be used:
    
      $ echo "list *write_sysrq_trigger+0x51" |gdb ~/k/vmlinux |grep "is in"
      (gdb) 0xffffffff815b5d83 is in driver_probe_device (/home/jpoimboe/git/linux/drivers/base/dd.c:378).
    
    (But note that when there are duplicate symbol names, gdb will only show
    the first symbol it finds.  faddr2line is recommended over gdb because
    it handles duplicates and it also does function size checking.)
    
    Here's an example of what a stack dump looks like after this change:
    
      BUG: unable to handle kernel NULL pointer dereference at           (null)
      IP: sysrq_handle_crash+0x45/0x80
      PGD 36bfa067 [   29.650644] PUD 7aca3067
      Oops: 0002 [#1] PREEMPT SMP
      Modules linked in: ...
      CPU: 1 PID: 786 Comm: bash Tainted: G            E   4.9.0-rc1+ #1
    
    
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.1-1.fc24 04/01/2014
      task: ffff880078582a40 task.stack: ffffc90000ba8000
      RIP: 0010:sysrq_handle_crash+0x45/0x80
      RSP: 0018:ffffc90000babdc8 EFLAGS: 00010296
      RAX: ffff880078582a40 RBX: 0000000000000063 RCX: 0000000000000001
      RDX: 0000000000000001 RSI: 0000000000000000 RDI: 0000000000000292
      RBP: ffffc90000babdc8 R08: 0000000b31866061 R09: 0000000000000000
      R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000
      R13: 0000000000000007 R14: ffffffff81ee8680 R15: 0000000000000000
      FS:  00007ffb43869700(0000) GS:ffff88007d400000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 0000000000000000 CR3: 000000007a3e9000 CR4: 00000000001406e0
      Stack:
       ffffc90000babe00 ffffffff81572d08 ffffffff81572bd5 0000000000000002
       0000000000000000 ffff880079606600 00007ffb4386e000 ffffc90000babe20
       ffffffff81573201 ffff880036a3fd00 fffffffffffffffb ffffc90000babe40
      Call Trace:
       __handle_sysrq+0x138/0x220
       ? __handle_sysrq+0x5/0x220
       write_sysrq_trigger+0x51/0x60
       proc_reg_write+0x42/0x70
       __vfs_write+0x37/0x140
       ? preempt_count_sub+0xa1/0x100
       ? __sb_start_write+0xf5/0x210
       ? vfs_write+0x183/0x1a0
       vfs_write+0xb8/0x1a0
       SyS_write+0x58/0xc0
       entry_SYSCALL_64_fastpath+0x1f/0xc2
      RIP: 0033:0x7ffb42f55940
      RSP: 002b:00007ffd33bb6b18 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
      RAX: ffffffffffffffda RBX: 0000000000000046 RCX: 00007ffb42f55940
      RDX: 0000000000000002 RSI: 00007ffb4386e000 RDI: 0000000000000001
      RBP: 0000000000000011 R08: 00007ffb4321ea40 R09: 00007ffb43869700
      R10: 00007ffb43869700 R11: 0000000000000246 R12: 0000000000778a10
      R13: 00007ffd33bb5c00 R14: 0000000000000007 R15: 0000000000000010
      Code: 34 e8 d0 34 bc ff 48 c7 c2 3b 2b 57 81 be 01 00 00 00 48 c7 c7 e0 dd e5 81 e8 a8 55 ba ff c7 05 0e 3f de 00 01 00 00 00 0f ae f8 <c6> 04 25 00 00 00 00 01 5d c3 e8 4c 49 bc ff 84 c0 75 c3 48 c7
      RIP: sysrq_handle_crash+0x45/0x80 RSP: ffffc90000babdc8
      CR2: 0000000000000000
    
    Suggested-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: default avatarJosh Poimboeuf <jpoimboe@redhat.com>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: Brian Gerst <brgerst@gmail.com>
    Cc: Denys Vlasenko <dvlasenk@redhat.com>
    Cc: H. Peter Anvin <hpa@zytor.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Link: http://lkml.kernel.org/r/69329cb29b8f324bb5fcea14d61d224807fb6488.1477405374.git.jpoimboe@redhat.com
    
    
    Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
    bb5e5ce5