linux-kernel - Re: [RFC PATCH 13/21] x86/asm/crypto: Fix frame pointer usage in aesni-intel

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: <20150721120657.GC11122@treble.redhat.com>
Date:	Tue, 21 Jul 2015 07:06:57 -0500
From:	Josh Poimboeuf <jpoimboe@...hat.com>
To:	Ingo Molnar <mingo@...nel.org>
Cc:	Andy Lutomirski <luto@...capital.net>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>, Michal Marek <mmarek@...e.cz>,
	Peter Zijlstra <peterz@...radead.org>,
	Andy Lutomirski <luto@...nel.org>,
	Borislav Petkov <bp@...en8.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andi Kleen <andi@...stfloor.org>,
	Pedro Alves <palves@...hat.com>, X86 ML <x86@...nel.org>,
	live-patching@...r.kernel.org,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH 13/21] x86/asm/crypto: Fix frame pointer usage in
 aesni-intel_asm.S

On Tue, Jul 21, 2015 at 10:00:16AM +0200, Ingo Molnar wrote:
> 
> * Josh Poimboeuf <jpoimboe@...hat.com> wrote:
> 
> > On Mon, Jul 20, 2015 at 08:30:52AM -0700, Andy Lutomirski wrote:
> > > On Fri, Jul 17, 2015 at 8:56 PM, Josh Poimboeuf <jpoimboe@...hat.com> wrote:
> > > > The reason I suggested to put FRAME in the macro name is to try to
> > > > prevent it from being accidentally used for leaf functions, where it
> > > > isn't needed.
> > > >
> > > 
> > > Could someone remind me why it isn't needed for leaf functions?
> > 
> > If a function doesn't call any other functions, then it won't ever show
> > up in a stack trace unless:
> > 
> > a) the function itself walks the stack, in which case the frame pointer
> >    isn't necessary; or
> > 
> > b) The function gets hit by an interrupt/exception, in which case frame
> >    pointers can't be 100% relied upon anyway.
> > 
> > I've noticed that gcc *does* seem to create stack frames for leaf functions.  
> > But it's inconsistent, because the early exit path of some functions will skip 
> > the stack frame creation and go straight to the return.
> > 
> > We could probably get a good performance boost with the 
> > -momit-leaf-frame-pointer flag.  Though it would make stack traces less reliable 
> > when a leaf function gets interrupted.
> 
> So in theory we could resolve this during the stack walk: when we pass from the 
> IRQ stack to the process stack we actually know the RIP of the interrupted 
> context, and could include that.

The problem is with the *caller* of the leaf function.  Without the
leaf's frame pointer there's no way to find the call site pointer on the
stack, so the leaf's caller gets skipped.

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