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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20170508131456.ssh5a5ilhod4kja6@treble>
Date:   Mon, 8 May 2017 08:14:56 -0500
From:   Josh Poimboeuf <jpoimboe@...hat.com>
To:     Vojtech Pavlik <vojtech@...e.com>
Cc:     hpa@...or.com, Ingo Molnar <mingo@...nel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Jiri Slaby <jslaby@...e.cz>,
        Andrew Morton <akpm@...ux-foundation.org>,
        live-patching@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        the arch/x86 maintainers <x86@...nel.org>,
        Andy Lutomirski <luto@...nel.org>,
        Jiri Kosina <jikos@...nel.org>
Subject: Re: [PATCH 7/7] DWARF: add the config option

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