linux-kernel - Re: [PATCH v2 07/15] x86/lib/copy_user_64.S: Convert to ALTERNATIVE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20150305093457.GA25419@gmail.com>
Date:	Thu, 5 Mar 2015 10:34:57 +0100
From:	Ingo Molnar <mingo@...nel.org>
To:	Borislav Petkov <bp@...en8.de>, Jiri Olsa <jolsa@...hat.com>,
	Arnaldo Carvalho de Melo <acme@...radead.org>,
	Adrian Hunter <adrian.hunter@...el.com>
Cc:	X86 ML <x86@...nel.org>, Andy Lutomirski <luto@...capital.net>,
	LKML <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH v2 07/15] x86/lib/copy_user_64.S: Convert to ALTERNATIVE_2


* Borislav Petkov <bp@...en8.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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/