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.
--
To unsubscribe from this list: send the line "unsubscribe live-patching" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
