linux-kernel - Re: [PATCH] x86/debug: Remove perpetually broken, unmaintainable dwarf annotations

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: <20150602144618.GA24773@treble.redhat.com>
Date:	Tue, 2 Jun 2015 09:46:18 -0500
From:	Josh Poimboeuf <jpoimboe@...hat.com>
To:	Ingo Molnar <mingo@...nel.org>
Cc:	Andy Lutomirski <luto@...capital.net>,
	Jan Beulich <JBeulich@...e.com>,
	Borislav Petkov <bp@...en8.de>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Ingo Molnar <mingo@...e.hu>, Brian Gerst <brgerst@...il.com>,
	Frédéric Weisbecker <fweisbec@...il.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Denys Vlasenko <dvlasenk@...hat.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	"Frank Ch. Eigler" <fche@...hat.com>
Subject: Re: [PATCH] x86/debug: Remove perpetually broken, unmaintainable
 dwarf annotations

On Tue, Jun 02, 2015 at 07:57:06AM +0200, Ingo Molnar wrote:
> * Andy Lutomirski <luto@...capital.net> wrote:
> > On Mon, Jun 1, 2015 at 12:45 PM, Josh Poimboeuf <jpoimboe@...hat.com> wrote:
> > > On Fri, May 29, 2015 at 10:47:31AM -0700, Andy Lutomirski wrote:
> > >> FWIW, musl is considering some kind of automatic annotation scheme:
> > >>
> > >> http://www.openwall.com/lists/musl/2015/05/13/5
> > >
> > > Thanks for the link!  I found a newer version of it here:
> > >
> > >   http://www.openwall.com/lists/musl/2015/05/31/5
> > >
> > > Overall I think that script is a really good solution.
> > >
> > > From what I can tell, it tracks the CFA (stack pointer) perfectly.
> > > (Which is actually pretty straightfoward if you just hook into function
> > > entry/exit, push/pop, and add/sub to rsp).
> > >
> > > It also does a nice job at making a best effort at tracking the caller's
> > > register values (which are less important than CFA but still nice to
> > > have).
> > 
> > It might be nice to be able to reliably unwind out from an exception / interrupt 
> > / syscall frame into userspace or into the kernel code that trapped, complete 
> > with registers.
> > 
> > In any event, we'll almost certainly have to manually annotate these weird types 
> > of entries.  I wonder if we could manage to annotate just the entry parts and 
> > let a magic script do the rest.
> 
> Even the entry parts we could help without uglifying the code:
> 
>  - either by adding a 'RET' instruction after IRET/SYSRET/SYSEXIT/etc. that the
>    tooling can recognize as 'return from function'. That's much nicer than ugly
>    annotations.
> 
>  - enhancing the tooling script to also recognize these instructions as function
>    returns - because they _are_ function returns.

I think the problem with the entry code (and other non-function asm
code) is that it's quite spaghetti-esque, with lots of jumps, returns,
calls, etc to random places.  There aren't enough constraints which
would help the tooling make sense of where execution begins and ends,
when registers are saved or trashed, etc.

Maybe over time we can figure out what constraints (and/or annotations)
are needed there.


-- 
Josh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/