Re: [PATCH v15 13/25] x86/reboot: Add ljmp instructions to stacktool whitelist

[Borislav Petkov <bp@alien8.de>]

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.