lkml.org 
[lkml]   [2012]   [Apr]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC PATCH -tip 00/16] in-kernel x86 disassember

* Masami Hiramatsu <masami.hiramatsu@gmail.com> wrote:

> Hi,
>
> Here is a series of patches of the in-kernel x86 disassembler
> for the latest tip tree.
> This will show you a pretty disassembled code instead of
> just a digital code sequence when you gets a kernel panic etc.
> (I know, we also have script/decodecode for the panic use)
>
> This feature is not for users, but mainly for kernel developers
> who can understand disassembly code of x86 ;). This is just like
> a joke feature in kernel. (yeah, I spend my spare time for this.
> It's my fun :))

Nice :-)

Wrt. testing: just wondering, could we eventually attempt to
create a user-space testcase for this as well? I.e. if we tried
to have a switch to emulate objdump output, we could check that
the in-kernel disassembler outputs the same sequence as objdump
-d, or so.

[ I realize that this does not cover SSE instructions, which do
sometimes occur in the vmlinux - but 99% of the instruction
stream is regular and would be a nice testcase. ]

> - Debugfs disassembler interface for kernel function. You can disassemble
> running kernel function on-line.

Nice :-)

> - Panic dump shows disassembly code instead of instruction byte stream.
> It generates more human-readable report. (I strongly recommend you to
> add a serial logger if it is enabled :))

This is the most useful short-term practical aspect I suspect.

> - Disassemble command for KDB. 'dis' command is now available.
> - User-land disassembly tool.

It would be nice to extend the output beyond the boring GNU
tooling, for example to auto-label branch targets instead of
relying on debuginfo.

This could be used for better visualization as well, instead of
the boring and hard to read GNU output:

ffffffff8175d500 <_raw_spin_lock>:
ffffffff8175d500: 55 push %rbp
ffffffff8175d501: b8 00 00 01 00 mov $0x10000,%eax
ffffffff8175d506: 48 89 e5 mov %rsp,%rbp
ffffffff8175d509: f0 0f c1 07 lock xadd %eax,(%rdi)
ffffffff8175d50d: 89 c2 mov %eax,%edx
ffffffff8175d50f: c1 ea 10 shr $0x10,%edx
ffffffff8175d512: 66 39 c2 cmp %ax,%dx
ffffffff8175d515: 74 13 je ffffffff8175d52a <_raw_spin_lock+0x2a>
ffffffff8175d517: 66 0f 1f 84 00 00 00 nopw 0x0(%rax,%rax,1)
ffffffff8175d51e: 00 00
ffffffff8175d520: f3 90 pause
ffffffff8175d522: 0f b7 07 movzwl (%rdi),%eax
ffffffff8175d525: 66 39 d0 cmp %dx,%ax
ffffffff8175d528: 75 f6 jne ffffffff8175d520 <_raw_spin_lock+0x20>
ffffffff8175d52a: 5d pop %rbp
ffffffff8175d52b: c3 retq
ffffffff8175d52c: 0f 1f 40 00 nopl 0x0(%rax)
the default 'human readable' output could be something much more
intelligent, like:

<_raw_spin_lock>:
push %rbp
mov $0x10000, %eax
mov %rsp, %rbp
lock xadd %eax, (%rdi)
mov %eax, %edx
shr $0x10, %edx
cmp %ax, %dx
je L2 #-----------------------------.
nop-7 |
|
L1: pause <-------------. |
movzwl (%rdi), %eax | |
cmp %dx, %ax | |
jne L1 #------------------------' |
|
L2: pop %rbp <------------------'
retq
This is much more readable, right? Yet it carries all the
essential information that the original output one carried.

If vector instructions (SEE, MMX, AVX) are in your list to
support then it would be and interesting use to combine this
with perf on x86 - which uses objdump right now. Perf could use
a programmatic, librarized disassembler for its assembly
annotation code.

That would allow new UI features like:

- proper highlighting of jump/branch instructions and
navigation along branch instructions (and visualization of
possible execution flow) as well.

- register modification and lifetime highlighting. If I click
on 'rax' then the output could show how this register gets
touched by the code, explicitly and implicitly (a common
assembly coding pitfall)

- summarization of usually irrelevant details, like the nop-7
example above.

Another very interesting usecase would be to invert it and
create a simpler parser and an in-kernel *assembler*: a GAS
replacement in essence. We could build the kernel using its own
assembler.

That could also be used for safe sandboxing: the disassembler
could be combined with the assembler to ensure that binary code
submitted to the kernel is 'safe' to execute - even in
kernel-space. A sha1 hash could be used to cache already
checked, 'safe' modules of code.

Thanks,

Ingo


\
 
 \ /
  Last update: 2012-04-02 09:07    [from the cache]
©2003-2011 Jasper Spaans