Re: [PATCH 0/5] x86: CVE-2017-5715, aka Spectre

[David Woodhouse <dwmw2 at infradead dot org>]

On Sun, 2018-01-14 at 21:52 +0100, Uros Bizjak wrote:
> On Sun, Jan 14, 2018 at 9:34 PM, David Woodhouse <dwmw2@infradead.org> wrote:
> > But sure, right now it isn't that might of a difference for me; my
> > implementation has changed since I made that reqeust. I have no
> > fundamental technical objection to the bare 'ax' naming. We can live
> > with either.
> > 
> > It's just that we've been asking for an agreement on the basics (the
> > command line we use, and the thunk names) for some days now, and this
> > is the first time we've had this discussion, and Linus has just taken
> > the patches.
> > 
> > That's still fine. I know we get no sympathy, and we *can* change the
> > Linux kernel between -rc8 and -final if we must, and change the Xen
> > patches too. I'd just rather not.
> Well, you did say that these are strange times ;)
> 
> From the user perspective, it would be more convenient to use the
> thunk names that are the same for 32bit and 64bit targets. If we
> ignore this fact, the difference is only a couple of lines in the
> compiler source which we also can live with. But please discuss my
> proposal also in the kernel community, and weight the benefits and
> drawbacks of each approach before the final decision.
> 
> Please pass the final decision to gcc community, and we'll implement it.

+Linus, Thomas.

Review on the GCC patches has led to a request that the thunk symbols
be changed from e.g. __x86_indirect_thunk_rax to
__x86_indirect_thunk_ax without the 'r'.

If we're going to change the thunk names, it's best to do it *right*
now before the 4.15-rc8 release.

I genuinely don't care at this point what the thunk names are. It's
just that Linus is probably preparing the -rc8 release as we speak, and
I'd want to do a new compiler build and set of tests if we make the
change. For that reason alone, I'm inclined to answer that we should
leave them as they are.

Attachment: smime.p7s
Description: S/MIME cryptographic signature