linux-kernel - Re: [PATCH 2/2] x86/asm: Fix inline asm call constraints for clang

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:   Thu, 21 Sep 2017 17:35:11 +0200
From:   Ingo Molnar <mingo@...nel.org>
To:     Josh Poimboeuf <jpoimboe@...hat.com>
Cc:     "H. Peter Anvin" <hpa@...or.com>, x86@...nel.org,
        linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
        Andy Lutomirski <luto@...nel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Alexander Potapenko <glider@...gle.com>,
        Dmitriy Vyukov <dvyukov@...gle.com>,
        Matthias Kaehlcke <mka@...omium.org>,
        Arnd Bergmann <arnd@...db.de>,
        Peter Zijlstra <peterz@...radead.org>,
        Andrey Ryabinin <aryabinin@...tuozzo.com>
Subject: Re: [PATCH 2/2] x86/asm: Fix inline asm call constraints for clang


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

> On Wed, Sep 20, 2017 at 10:32:43AM -0700, H. Peter Anvin wrote:
> > On 09/19/17 11:45, Josh Poimboeuf wrote:
> > > For inline asm statements which have a CALL instruction, we list the
> > > stack pointer as a constraint to convince GCC to ensure the frame
> > > pointer is set up first:
> > > 
> > >   static inline void foo()
> > >   {
> > >   	register void *__sp asm(_ASM_SP);
> > >   	asm("call bar" : "+r" (__sp))
> > >   }
> > > 
> > > Unfortunately, that pattern causes clang to corrupt the stack pointer.
> > > 
> > > There's actually an easier way to achieve the same goal in GCC, without
> > > causing trouble for clang.  If we declare the stack pointer register
> > > variable as a global variable, and remove the constraint altogether,
> > > that convinces GCC to always set up the frame pointer before inserting
> > > *any* inline asm.
> > > 
> > > It basically acts as if *every* inline asm statement has a CALL
> > > instruction.  It's a bit overkill, but the performance impact should be
> > > negligible.
> > > 
> > 
> > Again, probably negligible, but why do we need a frame pointer just
> > because we have a call assembly instruction?
> 
> It's frame pointer convention.  Without it, if dumping the stack from
> the called function, a function will get skipped in the stack trace.

BTW., could we perhaps relax this and simply phase out the frame pointer on x86, 
and simplify all our assembly in a cycle or two? ORC unwinder is working out very 
well so far. Live kernel patching can use ORC data just fine, and nothing else 
actually relies on frame pointers, right?

That would give one more register to assembly code.

I realize that we just rewrote a whole bunch of assembly code... but that was the 
price for ORC, in a way.

Thanks,

	Ingo