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: <20170507175915.ggwfusgvbwfqsvtz@gmail.com>
Date:   Sun, 7 May 2017 19:59:16 +0200
From:   Ingo Molnar <mingo@...nel.org>
To:     Josh Poimboeuf <jpoimboe@...hat.com>
Cc:     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>,
        "H. Peter Anvin" <hpa@...or.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

* Josh Poimboeuf <jpoimboe@...hat.com> wrote:

> One instance of the structure would exist for each time the stack
> pointer changes, e.g. for every function entry, push/pop, and rsp
> add/subtract.  The data could be assembled and sorted offline, possibly
> derived from DWARF, or more likely, generated by objtool.  After doing
> some rough calculations, I think the section size would be comparable to
> the sizes of the DWARF .eh_frame sections it would replace.

That's something I've been thinking about as well: if objtool generates the 
unwinder data structures then the kernel is not directly exposed to tooling bugs 
anymore.

A fair chunk of the fragility of DWARF comes from the fact that it's generated by 
a tool chain that we cannot fix as part of the kernel project. If GCC generates 
crap debuginfo, and GDB happens to work with it but the kernel not, we'll have to 
work it around in the kernel. If GCC starts bloating debuginfo in the future we 
are screwed as well, etc.

If objtool generates debuginfo then it's _our_ responsibility to have sane 
unwinder info and we obviously manage its structure and size as well. Win-win.

The unwinder itself should still do sanity checks, etc. (like all good debugging 
infrastructure code) - but the nature of the kernel's exposure to tool chain 
details changes in a very fundamental way.

So yes, I think this is a very good idea, assuming it works in practice! ;-)

Thanks,

	Ingo