linux-kernel - Re: [PATCH v3 01/13] x86/retpoline: Add initial retpoline support

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: <1515174510.29312.169.camel@infradead.org>
Date:   Fri, 05 Jan 2018 17:48:30 +0000
From:   David Woodhouse <dwmw2@...radead.org>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     "bp@...e.de" <bp@...e.de>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "peterz@...radead.org" <peterz@...radead.org>,
        "tim.c.chen@...ux.intel.com" <tim.c.chen@...ux.intel.com>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "ak@...ux.intel.com" <ak@...ux.intel.com>,
        "riel@...hat.com" <riel@...hat.com>,
        "keescook@...gle.com" <keescook@...gle.com>,
        "gnomes@...rguk.ukuu.org.uk" <gnomes@...rguk.ukuu.org.uk>,
        "pjt@...gle.com" <pjt@...gle.com>,
        "dave.hansen@...el.com" <dave.hansen@...el.com>,
        "luto@...capital.net" <luto@...capital.net>,
        "jikos@...nel.org" <jikos@...nel.org>,
        "gregkh@...ux-foundation.org" <gregkh@...ux-foundation.org>
Subject: Re: [PATCH v3 01/13] x86/retpoline: Add initial retpoline support

On Fri, 2018-01-05 at 09:28 -0800, Linus Torvalds wrote:
> 
> Yes, I would suggest against expecting altinstructions to have
> relocation information. They are generated in a different place, so..
> 
> That said, I honestly like the inline version (the one that is in the
> google paper first) of the retpoline more than the out-of-line one.
> And that one shouldn't have any relocagtion issues, because all the
> offsets are relative.
> 
> We want to use that one for the entry stub anyway, can't we just
> standardize on that one for all our assembly?

Sure, that's just a case of tweaking the macros a little to do it
inline instead of jumping to the thunk. I thunk judicious use of
__stringify() has resolved any issues I might have had with that
approach in the first place. However...

> If the *compiler* uses the out-of-line version, that's a separate
> thing. But for our asm cases, let's just make it all be the inline
> case, ok?
> 
> It also should simplify the whole target generation. None of this
> silly "__x86.indirect_thunk.\reg" crap with different targets for
> different register choices.

If we're going to let the compiler use the out-of-line version (which
we *want* to because otherwise we don't get to ALTERNATIVE it away as
appropriate), then we still need to emit the various
__x86.indirect_thunk.\reg thunks for the compiler to use anyway.

At that point, there isn't a *huge* benefit to doing the retpoline
inline in our own asm, when it might as well just be a jump to the
thunks which exist anyway. But neither do I have an argument *against*
doing so, so I'll happily tweak the NOSPEC_CALL/NOSPEC_JMP macros
accordingly if you really want...
Download attachment "smime.p7s" of type "application/x-pkcs7-signature" (5213 bytes)