This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH 0/5] x86: CVE-2017-5715, aka Spectre
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Markus Trippelsdorf <markus at trippelsdorf dot de>
- Cc: Sandra Loosemore <sandra at codesourcery dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Chandler Carruth <chandlerc at gmail dot com>
- Date: Mon, 8 Jan 2018 03:40:33 -0800
- Subject: Re: [PATCH 0/5] x86: CVE-2017-5715, aka Spectre
- Authentication-results: sourceware.org; auth=none
- References: <20180107225904.11535-1-hjl.tools@gmail.com> <b79e3ed1-8ecb-326e-4171-ffebf315a2ec@codesourcery.com> <20180108065533.GA249@x4>
On Sun, Jan 7, 2018 at 10:55 PM, Markus Trippelsdorf
<markus@trippelsdorf.de> wrote:
> On 2018.01.07 at 21:07 -0700, Sandra Loosemore wrote:
>> On 01/07/2018 03:58 PM, H.J. Lu wrote:
>> > This set of patches for GCC 8 mitigates variant #2 of the speculative execution
>> > vulnerabilities on x86 processors identified by CVE-2017-5715, aka Spectre. They
>> > convert indirect branches to call and return thunks to avoid speculative execution
>> > via indirect call and jmp.
>>
>> I have a general documentation issue with all the new command-line
>> options and attributes added by this patch set: the documentation is
>> very implementor-speaky and doesn't explain what user-level problem
>> they're trying to solve.
>>
>> E.g. to take just one example
>>
>> > +@item function_return("@var{choice}")
>> > +@cindex @code{function_return} function attribute, x86
>> > +On x86 targets, the @code{function_return} attribute causes the compiler
>> > +to convert function return with @var{choice}. @samp{keep} keeps function
>> > +return unmodified. @samp{thunk} converts function return to call and
>> > +return thunk. @samp{thunk-inline} converts function return to inlined
>> > +call and return thunk. @samp{thunk-extern} converts function return to
>> > +external call and return thunk provided in a separate object file.
>>
>> Why would you want to mess with call and return code generation in this
>> way? The documentation doesn't say.
>>
>> For thunk-extern, is the programmer supposed to provide the thunk? How
>> would you go about implementing the missing bit of code? What should it
>> do? I'm compiler implementor and I wouldn't even know how to use this
>> feature by reading the manual; how would an ordinary application
>> programmer who isn't familiar with GCC internals know how to use it?
>>
>> If the goal here is to tell GCC to produce code that is protected
>> against the Spectre vulnerability, perhaps simplify this to adding just
>> one option that controls all the things you've given separate options
>> and attributes for?
>
> Also it would be good to coordinate with the LLVM guys: They currently
> use -mretpoline and -mretpoline_external_thunk.
> I agree with Sandra that a single master option like -mretpoline would
> be better.
Our current goal is to compile Linux kernel. We won't change the generated
codes. We will change the command options only if we add a late generic RTL
pass.
--
H.J.