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

["Woodhouse, David" <dwmw at amazon dot co dot uk>]

On Thu, 2018-01-18 at 08:52 +0100, Uros Bizjak wrote:
> This puts an extra burden on the developer, which has to use correct
> thunk name in their code. Sure, this can be solved trivially with
> #ifdef __x86_64__, so the issue is minor, but I thought it has to be
> mentioned before the name is set in stone.

Except the developer can mostly use the inline thunk and not have to
worry their pretty little heads about it. And the kernel developers who
*have* chosen to implement their own thunk (and who requested the
thunk-extern variant in the first place) have explicitly asked for the
symbol name to be as it is.

I spent a happy few hours on Sunday night looking at this. Seriously,
in neither the thunk implementation nor the call sites (in explicit
asm) was it easier. It was horrid — just look at the patch I sent out
with the footnote "let's not do this".

In the thunk I still had the actual register name with the 'e' or the
'r' in a macro argument anyway, because I had to deal with the value
from that register. So the thunk macro ended up taking *two* arguments
because its name now didn't match what it had to call the register.

And in the call sites I was putting the target into a register again
using either 'eax' or 'rax' form, then having to branch to the thunk
using the different '_ax' form. It just hurt.

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