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 -- 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
