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".

[Florian Weimer <fweimer at redhat dot com>]

On 01/05/2018 06:51 PM, Sriraman Tallam wrote:
> > > If we think this is a problem that needs to be fixed, we should remove the
> > > indirect call altogether, and have the dynamic linker generate a direct call
> > > at load time.  There are few constraints associated with that (4 GiB total
> > > application + DSO size, some SELinux users will unhappy, lack of lazy
> > > binding support), but at least it can be turned on in practice.

> How practical is this really for 64-bit address space where libc is
> not mapped close to the binary.

libc can be mapped anywhere.  The dynamic loader does that, not the 
kernel, so the placement is really up to the loader.  What you cannot do 
is place the dynamic loader itself close to the rest of the program 
binaries because the kernel loads both the program and the dynamic 
loader (the latter as the program interpreter).  But references to the 
loader are rare and could still be handled with redirection through libc.

Thanks,
Florian