[PATCH 0/5] x86: CVE-2017-5715, aka Spectre
Markus Trippelsdorf
markus@trippelsdorf.de
Mon Jan 8 08:00:00 GMT 2018
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.
--
Markus
More information about the Gcc-patches
mailing list