* Borislav Petkov <b...@alien8.de> wrote:
> On Thu, Mar 05, 2015 at 01:32:49AM +0100, Ingo Molnar wrote:
> > We could also do a (limited) relink during early bootup, as part of
> > the alternatives patching pass in essence: for that we need to stick
> > the relocation info into a section and put that into the vmlinux.
>
> Oh, you want us to do our own asm inlining, so to speak, and save us
> even a CALL. [...]
No, I didn't want to go that far - I just suggested to patch the CALL
to the target function.
But it's an equivalent method to patch in the most popular full
function variants via ALTERNATIVE_2().
> Also, with shifted virtual addresses at boot time, debuggability
> becomes a serious pain because "objdump -D vmlinux" output is
> worthless all of a sudden.
Yeah, that way lies madness.
> For example, even during doing those patches, I had to go and dump
> kernel memory to see what actually gets patched in. And without kvm
> and the monitor console, I would've had a serious hard time. If you
> change larger portions of the kernel at early boot, that might make
> the whole endeavor of debugging a serious undertaking. I already
> dread the moment when I'd have to look at a kaslr'ed splat.
Ha! There's a neat alternatives debugging trick with perf that you
might not know about: if you run 'perf top' as root then perf will use
/proc/kcore to disassemble the live kernel image and if you look at
the assembly output of hot functions then you'll see the real, patched
instructions on the live kernel, not the vmlinux instructions.
I have two enhancement suggestions to the perf tooling developers for
this usecase:
1) We should perhaps add a 'perf top --all-kernel-symbols' kind of
mode (with a better command name), which would make all kernel
symbols visible in 'perf top' at startup, which could be searched
and inspected freely - without having to first wait for them to
show up in the profile?
2) it would be absolutely, totally nice to have a TUI mode where
the raw address and raw instruction opcodes are output as well,
like objdump does:
ffffffff818740e2: 90 nop
ffffffff818740e3: 48 83 ec 78 sub $0x78,%rsp
ffffffff818740e7: e8 64 03 00 00 callq
ffffffff81874450 <save_paranoid>
ffffffff818740ec: 48 89 e7 mov %rsp,%rdi
ffffffff818740ef: 48 8b 74 24 78 mov 0x78(%rsp),%rsi
ffffffff818740f4: 48 c7 44 24 78 ff ff movq
$0xffffffffffffffff,0x78(%rsp)
The 'o' hotkey already shows the raw address - but the raw
instruction opcodes are still hidden - would be nice to get them
too!
This kind of disassembly/annotation mode could be called 'perf
inspect' or 'perf disasm' or 'perf kernel-annotate'? It would be a
perf.data-less mode of operation, i.e. like 'perf top'.
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
