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]

Date:   Mon, 8 May 2017 08:15:34 +0200
From:   Ingo Molnar <mingo@...nel.org>
To:     Andy Lutomirski <luto@...capital.net>
Cc:     Josh Poimboeuf <jpoimboe@...hat.com>,
        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

* Andy Lutomirski <luto@...capital.net> wrote:

> I think that, if the code were sufficiently robust, it would be handy if the 
> unwinder displayed function arguments.  DWARF can do that to a limited extent.
> 
> That being said, having a simpler table format would probably cover most of the 
> use cases.

I'd say that if objtool generates the kernel's debuginfo, it all becomes a kernel 
internal matter to a large degree: we can add function argument display support as 
well and see what effect it has on data structure size and complexity - it would 
certainly be a nice improvement in oops output to see function arguments.

But it should all start from a minimum complexity step (which will be complex 
enough!) and the first step should be stack trace display, in a performance 
optimized data structure, to allow both kernel stack dumps and various tracing and 
other instrumentation facilities that make use of the kernel's dwarf-ish unwider 
as-is.

The goal of this first step would be to allow x86 to drop generating the RBP frame 
pointer:

 - This shrinks kernel text and instruction count (by 1-2% IIRC),
 - speeds up certain code paths measurably,
 - plus it also allows larger functions to use one more general purpose register.

... so it's a good thing to have, if and only if the unwinder's fragility and 
complexity does not kill us. And much of that fragility comes from who generates 
the debuginfo ...

Thanks,

	Ingo