[tip:x86/asm] x86/dumpstack: Remove kernel text addresses from stack dump

2016-10-25 Thread tip-bot for Josh Poimboeuf 
Commit-ID:  bb5e5ce545f2031c96f7901cd8d1698ea3ca4c9c
Gitweb: http://git.kernel.org/tip/bb5e5ce545f2031c96f7901cd8d1698ea3ca4c9c
Author: Josh Poimboeuf 
AuthorDate: Tue, 25 Oct 2016 09:51:12 -0500
Committer:  Ingo Molnar 
CommitDate: Tue, 25 Oct 2016 18:40:37 +0200

x86/dumpstack: Remove kernel text addresses from stack dump

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) 0x815b5d83 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: GE   4.9.0-rc1+ #1
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.1-1.fc24 
04/01/2014
  task: 880078582a40 task.stack: c9ba8000
  RIP: 0010:sysrq_handle_crash+0x45/0x80
  RSP: 0018:c9babdc8 EFLAGS: 00010296
  RAX: 880078582a40 RBX: 0063 RCX: 0001
  RDX: 0001 RSI:  RDI: 0292
  RBP: c9babdc8 R08: 000b31866061 R09: 
  R10: 0001 R11:  R12: 
  R13: 0007 R14: 81ee8680 R15: 
  FS:  7ffb43869700() GS:88007d40() knlGS:
  CS:  0010 DS:  ES:  CR0: 80050033
  CR2:  CR3: 7a3e9000 CR4: 001406e0
  Stack:
   c9babe00 81572d08 81572bd5 0002
    880079606600 7ffb4386e000 c9babe20
   81573201 880036a3fd00 fffb c9babe40
  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:7ffd33bb6b18 EFLAGS: 0246 ORIG_RAX: 0001
  RAX: ffda RBX: 0046 RCX: 7ffb42f55940
  RDX: 0002 RSI: 7ffb4386e000 RDI: 0001
  RBP: 0011 R08: 7ffb4321ea40 R09: 7ffb43869700
  R10: 7ffb43869700 R11: 0246 R12: 00778a10
  R13: 7ffd33bb5c00 R14: 0007 R15: 0010
  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  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: c9babdc8
  CR2: 

Suggested-by: Linus Torvalds 
Signed-off-by: Josh Poimboeuf 
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: 
http://lkml.kernel.org/r/69329cb29b8f324bb5fcea14d61d224807fb6488.1477405374.git.jpoim...@redhat.com
Signed-off-by: Ingo Molnar

[tip:x86/asm] x86/dumpstack: Remove kernel text addresses from stack dump

2016-10-25 Thread tip-bot for Josh Poimboeuf 
Commit-ID:  bb5e5ce545f2031c96f7901cd8d1698ea3ca4c9c
Gitweb: http://git.kernel.org/tip/bb5e5ce545f2031c96f7901cd8d1698ea3ca4c9c
Author: Josh Poimboeuf 
AuthorDate: Tue, 25 Oct 2016 09:51:12 -0500
Committer:  Ingo Molnar 
CommitDate: Tue, 25 Oct 2016 18:40:37 +0200

x86/dumpstack: Remove kernel text addresses from stack dump

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) 0x815b5d83 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: GE   4.9.0-rc1+ #1
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.1-1.fc24 
04/01/2014
  task: 880078582a40 task.stack: c9ba8000
  RIP: 0010:sysrq_handle_crash+0x45/0x80
  RSP: 0018:c9babdc8 EFLAGS: 00010296
  RAX: 880078582a40 RBX: 0063 RCX: 0001
  RDX: 0001 RSI:  RDI: 0292
  RBP: c9babdc8 R08: 000b31866061 R09: 
  R10: 0001 R11:  R12: 
  R13: 0007 R14: 81ee8680 R15: 
  FS:  7ffb43869700() GS:88007d40() knlGS:
  CS:  0010 DS:  ES:  CR0: 80050033
  CR2:  CR3: 7a3e9000 CR4: 001406e0
  Stack:
   c9babe00 81572d08 81572bd5 0002
    880079606600 7ffb4386e000 c9babe20
   81573201 880036a3fd00 fffb c9babe40
  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:7ffd33bb6b18 EFLAGS: 0246 ORIG_RAX: 0001
  RAX: ffda RBX: 0046 RCX: 7ffb42f55940
  RDX: 0002 RSI: 7ffb4386e000 RDI: 0001
  RBP: 0011 R08: 7ffb4321ea40 R09: 7ffb43869700
  R10: 7ffb43869700 R11: 0246 R12: 00778a10
  R13: 7ffd33bb5c00 R14: 0007 R15: 0010
  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  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: c9babdc8
  CR2: 

Suggested-by: Linus Torvalds 
Signed-off-by: Josh Poimboeuf 
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: 
http://lkml.kernel.org/r/69329cb29b8f324bb5fcea14d61d224807fb6488.1477405374.git.jpoim...@redhat.com
Signed-off-by: Ingo Molnar 
---
 arch/x86/include/asm/kdebug.h |  1 -
 arch/x86/kernel/dumpstack.c   | 18 --
 arch/x86/kernel/process_32.c  |  7 +++
 arch/x86/kernel/process_64.c  |  6 +++---
 arch/x86/mm/fault.c   |  3