linux-kernel - Re: [PATCH v15 21/25] x86/asm: Create stack frames in rwsem functions

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]

Date:	Tue, 12 Jan 2016 15:40:22 +0100
From:	Borislav Petkov <bp@...en8.de>
To:	Josh Poimboeuf <jpoimboe@...hat.com>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>, x86@...nel.org,
	linux-kernel@...r.kernel.org, live-patching@...r.kernel.org,
	Michal Marek <mmarek@...e.cz>,
	Peter Zijlstra <peterz@...radead.org>,
	Andy Lutomirski <luto@...nel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andi Kleen <andi@...stfloor.org>,
	Pedro Alves <palves@...hat.com>,
	Namhyung Kim <namhyung@...il.com>,
	Bernd Petrovitsch <bernd@...rovitsch.priv.at>,
	Chris J Arges <chris.j.arges@...onical.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Jiri Slaby <jslaby@...e.cz>,
	Arnaldo Carvalho de Melo <acme@...nel.org>
Subject: Re: [PATCH v15 21/25] x86/asm: Create stack frames in rwsem functions

On Tue, Jan 12, 2016 at 08:36:48AM -0600, Josh Poimboeuf wrote:
> Ingo made a similar suggestion a while back:
> 
>   https://lkml.kernel.org/r/20150717194307.GA26757@gmail.com
> 
> But the frame stuff can't be folded into ENTRY/ENDPROC because we don't
> need to create a stack frame for *all* functions, but rather only for
> non-leaf functions.
> 
> So then we considered something like:
> 
>   FUNCTION_ENTRY(func)
>   FUNCTION_RETURN(func)
> 
> for non-leaf functions, and:
> 
>   LEAF_FUNCTION_ENTRY(func)
>   LEAF_FUNCTION_RETURN(func)
> 
> for leaf functions.
> 
> But that was too inflexible for the case where a function ends with a
> jump instead of a return.

Aah, there it is, thanks!

It actually does ring a bell. Ok. I'm guessing the expectation is that
we're not going to sprinkle those excessively but use them only in asm
code. Which should be relatively seldom, especially since we're moving
more and more stuff to C.

Thanks.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.