Re: [PATCH 7/7] DWARF: add the config option

[Josh Poimboeuf <jpoimboe@redhat.com>]

On Mon, May 08, 2017 at 09:50:54AM +0200, Vojtech Pavlik wrote:
> On Sun, May 07, 2017 at 04:48:36PM -0500, Josh Poimboeuf wrote:
> 
> > > Can objtool verify the unwinder at each address in the kernel, or is that an AI-complete problem?
> > 
> > It can't verify the *unwinder*, but it can verify the data which is fed
> > to the unwinder (either DWARF or the structs I proposed above).  For
> > each function, it follows every possible code path, and it can keep
> > track of the stack pointer while doing so.
> 
> In that case, the kernel build process can verify the DWARF data and its
> compatibility with the kernel unwinder by running the unwinder against
> each kernel code address verifying the output

If I understand the idea correctly, we'd have to make the unwinder
dual-purpose such that it can run both in the kernel and in some kind of
user space objtool test harness.  The stack wouldn't be real, so
presumably each iteration of the test would only unwind a frame
associated with the current function.

It wouldn't be able to test edge cases like entry code and generated
code which aren't normal "functions", which objtool currently has no way
of understanding.  Also it wouldn't test how the unwinder deals with
corrupt DWARF data or corrupt stacks, unless we integrated some kind of
fuzzer in the harness.

And, at the end of the day, we'd still just be testing in an artificial
unit test environment.  So I'm not really crazy about the idea.

> and bail if there is a bug in the toolchain that affects it.

Objtool can already find _toolchain_ bugs without having to run the
unwinder in some kind of emulator.  It can't find _unwinder_ bugs, but I
really think such testing should be done at runtime in the unwinder's
native kernel environment.

-- 
Josh