[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160115104145.GC25104@pd.tnic>
Date: Fri, 15 Jan 2016 11:41:45 +0100
From: Borislav Petkov <bp@...en8.de>
To: Josh Poimboeuf <jpoimboe@...hat.com>
Cc: Ingo Molnar <mingo@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
"H. Peter Anvin" <hpa@...or.com>, x86@...nel.org,
linux-kernel@...r.kernel.org, live-patching@...r.kernel.org,
Michal Marek <mmarek@...e.cz>,
Peter Zijlstra <peterz@...radead.org>,
Andy Lutomirski <luto@...nel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Andi Kleen <andi@...stfloor.org>,
Pedro Alves <palves@...hat.com>,
Namhyung Kim <namhyung@...il.com>,
Bernd Petrovitsch <bernd@...rovitsch.priv.at>,
Chris J Arges <chris.j.arges@...onical.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Jiri Slaby <jslaby@...e.cz>,
Arnaldo Carvalho de Melo <acme@...nel.org>
Subject: Re: [PATCH v15 13/25] x86/reboot: Add ljmp instructions to stacktool
whitelist
On Fri, Jan 15, 2016 at 12:06:52AM -0600, Josh Poimboeuf wrote:
> - xen_cpuid() uses some custom xen instructions which start with
> XEN_EMULATE_PREFIX. It corresponds to the following x86 instructions:
>
> ffffffff8107e572: 0f 0b ud2
> ffffffff8107e574: 78 65 js ffffffff8107e5db <xen_get_debugreg+0xa>
> ffffffff8107e576: 6e outsb %ds:(%rsi),(%dx)
>
> Apparently(?) xen treats the ud2 special when it's followed by "78 65
> 6e". This is confusing for stacktool because ud2 is normally a dead
> end, and it thinks the instructions after it will never run.
>
> (In theory stacktool could be taught to understand this hack, but
> that's a bad idea IMO)
Why, because it is not generic enough?
Well, you could add a cmdline option "--kernel" which is supplied when
checking the kernel and such kernel "idiosyncrasies" are handled only
then and there. And since the tool is part of the kernel, changes to
XEN_EMULATE_PREFIX, will have to be updated in stacktool too...
> - The error path in arch/x86/net/bpf_jit.S uses 'leaveq' to do a double
> return so that it returns from its caller's context. stacktool
> doesn't know how to distinguish this from a frame pointer programming
> bug. I think the only way to avoid a whitelist marker here would be
> to rewrite the bpf code to conform with more traditional rbp usage
> (but I don't know if that would really be a good idea because it would
> probably result in slower/more code).
Could also be part of the "--kernel"-specific checking and you could
match the containing ELF symbol bpf_error...
> - __bpf_prog_run() uses a jump table:
>
> goto *jumptable[insn->code];
>
> stacktool doesn't have an x86 emulator, so it doesn't know how to
> deterministically follow all possible branches for a dynamic jump.
>
> - schedule() mucks with the frame pointer which is normally not allowed.
I think if we put all those checks that under --kernel, the tool would
remain generic enough.
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
Powered by blists - more mailing lists