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: <20150720075611.GA11874@gmail.com>
Date:	Mon, 20 Jul 2015 09:56:11 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	Josh Poimboeuf <jpoimboe@...hat.com>
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


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

> On Sat, Jul 18, 2015 at 04:51:16AM +0200, Ingo Molnar wrote:
> > Note what the names _don't_ contain: that we generate debug info! That fact is not 
> > present in the naming, and that's very much intentional, because the precise form 
> > of debug info is conditional:
> > 
> >   - if CONFIG_FRAME_POINTERS=y then we push/pop a stack frame
> > 
> >   - if (later on) we do CFI annotations we don't push/pop a stack frame but emit 
> >     CFI debuginfo
> 
> According to current plan, the macro won't add CFI annotations.  That will be 
> done instead by a separate tool.  So the macro really is frame pointer specific.

Still the same argument applies: it's a debug info detail we should hide as much 
as sensibly possible. In the CONFIG_FRAME_POINTERS=y case it will be code, in the 
future !CONFIG_FRAME_POINTERS case it will be nothing.

> > In that sense 'FRAME' should never be in these names I think, nor 'PROC' 
> > (which is not symmetric).
> > 
> > Plus all 3 variants I suggested are very easy to remember, why I'd always have 
> > to look up any non-symmetric macro name called 'PROC'...
> 
> 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.

Well, we could use LEAF_FUNCTION to mark that fact.

Wether a function written in assembly is a leaf function or not is a higher level 
(and thus more valuable) piece of information whether we generate frame pointer 
debuginfo or not.

> Also the naming of FUNCTION_ENTRY and FUNCTION_RETURN doesn't do anything to 
> distinguish them from the already ubiquitous ENTRY and ENDPROC.  So as a kernel 
> developer it seems confusing to me, e.g. how do I remember when to use 
> FUNCTION_ENTRY vs ENTRY?

'ENDPROC' is really leftover from older debuginfo cruft, it's not a valuable 
construct IMHO, even if it's (sadly) ubiquitious.

We want to create new, clean, as minimal as possible and as clearly named as 
possible debuginfo constructs from first principles.

Thanks,

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