Re: Gold Linker Patch: Introduce the "retpoline" x86 mitigation technique for variant #2 of the speculative execution vulnerabilities disclosed today, specifically identified by CVE-2017-5715 and in some places called "spectre".

["Sriraman Tallam via binutils" <binutils at sourceware dot org>]

Hi Cary,

On Sun, Jan 7, 2018 at 3:14 PM, Cary Coutant <ccoutant@gmail.com> wrote:
>> We aren't patching linkers just because we can. ;]
>
> Chandler, if I didn't know you personally, I'd take offense. Hmm,
> maybe I took a wee bit of offense, even so. :-) Snark isn't going to
> get you anywhere; it's more likely to close minds.
>
> The details of these vulnerabilities are out there now, and your
> little circle is much bigger. That means you're now exposed to people
> with different experiences and possibly more expertise. Even if you've
> already been down certain paths and answered certain questions, you're
> going to need to do it again for the rest of us. People on this thread
> are asking reasonable questions, and if you want help and cooperation,
> those questions deserve serious answers. Together, we may even come up
> with better solutions.
>
> In particular, I'd like to know your answer to Alan's question about
> the performance implications of deploying slow shared libraries where
> not all applications need this mitigation, and the suggestion to just
> compile secure apps statically. I'd like to know your answer to HJ's
> suggestion to eliminate the PLT altogether (I have an answer to that,
> but I'd like to know yours).

Let me try to answer some of these questions since these were
discussed and considered:

* Plain Static linking is going to be a problem since it does not work
with PIE + static.  We have investigated using musl libc to enable
static linking + PIE and we had somebody who was successfully able to
link the dynamic relocator within a statlic binary to make PIE work
but it looks like it is going to be quite a while before this can be
deployed.
* We are looking at partially statically linking hot memops to remove
the PLT + ifunc penalty for these calls.  I understand that we may
still have to rebuild libc.so to use retpoline maybe.
* Regarding what HJ said, unless I misunderstood, I believe he is
referring to using fno-plt.  We considered that but the problem is the
indirect jump still exists, but now at the call site.  The mitigation
would still be necessary at the call site as it is still exposed to
the attack.

This is based on my limited understanding of the vulnerabilities and
the exploits.  Thanks for reviewing and my apologies if some of the
discussions/comments were offensive.

Thanks
Sri

>
> I've approved Sri's patch, in the hope that it's a short-term
> mitigation strategy that we can retire in a reasonable short period of
> time, and I'll be receptive to a follow-on patch that improves the
> code sequences as discussed in the LLVM review thread. I really don't
> want to get into the business of changing the ABI for this, though.
>
> -cary