linux-kernel - Re: [RFC PATCH 3/4] x86/asm: Make alternative macro interfaces more clear and consistent

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: <20170831172542.k5qchwmgckdcnc6d@treble>
Date:   Thu, 31 Aug 2017 12:25:42 -0500
From:   Josh Poimboeuf <jpoimboe@...hat.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     the arch/x86 maintainers <x86@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Ingo Molnar <mingo@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        "H. Peter Anvin" <hpa@...or.com>,
        Andy Lutomirski <luto@...nel.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>
Subject: Re: [RFC PATCH 3/4] x86/asm: Make alternative macro interfaces more
 clear and consistent

On Thu, Aug 31, 2017 at 09:11:54AM -0700, Linus Torvalds wrote:
> On Thu, Aug 31, 2017 at 7:11 AM, Josh Poimboeuf <jpoimboe@...hat.com> wrote:
> >
> > Make the following changes:
> >
> > - Give alternative_io(), alternative_call(), and alternative_call_2()
> >   consistent interfaces.  The constraints are provided by use of the
> >   OUTPUTS(), INPUTS(), and CLOBBERS() macros.
> 
> I really think those macro names are way too generic. Putting them in
> a core header file and expecting people to never use them is wrong.
> 
> So please rename things like "OUTPUTS()" to "ASM_OUTPUTS()" or something.
> 
> Yes, it might look slightly worse in the asm expansion.  And no, we
> don't actually seem to have anybody using those right now, but I did
> find people using both OUTPUT and INPUT in some C files, so those
> names are clearly not very unique or distinct.

Makes sense.  I can prepend them with "ASM_".

> On the whole, I'm not entirely sure this is the right approach. I
> think we should
> 
>  (a) approach clang about their obvious bug (a compiler that clobbers
> %rsp because we mark it as in/out is clearly buggy)

Yeah, this would be a good idea.

>  (b) ask gcc people if there's some other alternative that would work
> with clang as-is rather than the "mark %rsp register as clobbered"
>
> I couldn't actually find the %rsp trick in any docs, I assume it came
> from discussions with gcc developers directly. Maybe there is
> something else we could do that doesn't upset clang?

There have been a few other ideas which have *almost* worked:

1) Make the 'register void *__sp asm(_ASM_SP)' a global variable instead
   of a local one.  This works for GCC and doesn't break clang.  However
   it resulted in a lot of changed code on the GCC side.  It looked like
   some optimizations had been disabled, even in functions which
   shouldn't have been affected.

2) Put "sp" in the clobbers list instead of as an i/o constraint.  This
   mostly works for GCC, and doesn't break clang.  However, it causes
   GCC to insert a "lea -0x10(%rbp),%rsp" in the epilogue of every
   affected function.

I can ping the GCC list again and see if there are any other ideas.

> Perhaps we can mark the frame pointer as an input, for example? Inputs
> also have the advantage that appending to the input list doesn't
> change the argument numbering, so we don't need to worry about
> numbered arguments (not that I mind the naming of arguments, but I
> kind of hate having to do it as part of this series).

I'll give it a shot :-)

I'm about to disappear for a few days to celebrate the American labor
movement, so I'll try to follow up on this stuff next week.

-- 
Josh