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: <20150720135930.GB7326@treble.redhat.com>
Date:	Mon, 20 Jul 2015 08:59:30 -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 Mon, Jul 20, 2015 at 09:56:11AM +0200, Ingo Molnar 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.
> 
> 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.

Ok. So if I understand right, the proposal is:

Replace *all* x86 usage of ENTRY/ENDPROC with either:

FUNCTION_ENTRY(func)
FUNCTION_RETURN(func)

or

LEAF_FUNCTION_ENTRY(func)
LEAF_FUNCTION_RETURN(func)

Those sound fine to me.


I should point out that there are still a few cases where the more
granular FRAME/ENDFRAME and ENTRY/ENDPROC macros would still be needed.

For example, if the function ends with a jump instead of a ret.  If the
jump is a sibling call, the code would look like:

FUNCTION_ENTRY(func)
	...
	ENDFRAME
	jmp another_func
ENDPROC(func)


Or if it's a jump within the function to an internal ret:

FUNCTION_ENTRY(func)
	...
1:	...
	ENDFRAME
	ret
2:	...
	jmp 1b
ENDPROC(func)


Or if it jumps to some shared code before returning:

FUNCTION_ENTRY(func_1)
	...
	jmp common_return
ENDPROC(func_1)

FUNCTION_ENTRY(func_2)
	...
	jmp common_return
ENDPROC(func_2)

common_return:
	...
	ENDFRAME
	ret


So in some cases we'd still need the more granular macros, unless we
decided to make special macros for these cases as well.

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