Decoding Stack from kernel OOPS message

[valdis.kletnieks@vt.edu (valdis.kletnieks at vt.edu)]

On Tue, 13 Feb 2018 14:47:32 +0300, "Matwey V. Kornilov" said:

> Well, It is not clear to me. First, what is the purpose to dump the
> stack? Second, when I use gdb with ordinary user-space applications,
> then for every execution step I can do commands to print variables or
> expressions. It is obvious that gdb has mapping between variables in
> the source code and memory/register locations for any specific step.
> Isn't this mapping derivable from debug info?

There's two places that the info can be found - when the kernel splats
the error message into the dmesg buffer, and in userspace when you're
looking at the wreckage.

Note that the info you're looking at is in a file on disk - and thus off-limits
to the kernel. Doing file I/O inside the kernel is ugly enough, but doing it
while processing an error condition is totally beyond the pale (it's able to
unwind the function names from the stack traceback because *that* info
is already loaded into memory for many configurations of the kernel).

The second time is when you're looking at gdb after the fact - at which point
you need to worry about stuff like KALSR and so on.  Also, you're no longer
looking at a live stack in memory, you're looking at the output of a bunch of
printf statements - that adds to the challenge.

Have you looked at using objdump?  You'll need to figure out which .o/.ko has
the function in it, but then.  (As always figuring out what asm lines up with what
C code is left as an exercise for the programmer, but 90% of the time once you
know what register has the bad value in it, you can work backwards to either
a global variable or a value passed in a function parameter).

[/usr/src/linux-next] objdump -d arch/x86/lib/usercopy_64.o | head -20

arch/x86/lib/usercopy_64.o:     file format elf64-x86-64


Disassembly of section .text:

0000000000000000 <__clear_user>:
   0:	e8 00 00 00 00       	callq  5 <__clear_user+0x5>
   5:	55                   	push   %rbp
   6:	48 89 e5             	mov    %rsp,%rbp
   9:	41 54                	push   %r12
   b:	49 89 fc             	mov    %rdi,%r12
   e:	48 c7 c7 00 00 00 00 	mov    $0x0,%rdi
  15:	53                   	push   %rbx
  16:	48 89 f3             	mov    %rsi,%rbx
  19:	be 13 00 00 00       	mov    $0x13,%esi
  1e:	e8 00 00 00 00       	callq  23 <__clear_user+0x23>
  23:	90                   	nop
  24:	90                   	nop
  25:	90                   	nop

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 486 bytes
Desc: not available
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20180213/8ac3186e/attachment.sig>