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
| ||
|
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/
Powered by blists - more mailing lists