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".
Mon Jan 8 18:40:00 GMT 2018
On 01/08/2018 07:35 PM, Sriraman Tallam wrote:
> On Mon, Jan 8, 2018 at 10:23 AM, Florian Weimer <firstname.lastname@example.org> wrote:
>> On 01/08/2018 07:19 PM, Sriraman Tallam wrote:
>>> * 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.
>> But you'll have to patch GCC anyway to change the opcode sequence for
>> indirect jumps (just think of vtable dispatch), and then -fno-plt most
>> likely would move the dynamic linker and PLT stubs completely out of the
> * Yes, you are right and we did work to patch LLVM with this,
> * If we use fno-plt, we could just do the work of patching the call
> site in the compiler and completely avoid the linker. We did note
> that, but the downside is losing out on lazy binding which could
> affect mobile applications where I believe this is pretty crucial,
I don't know what âmobile applicationsâ are, but most distributions make
BIND_NOW mandatory, even though it does affect shell script performance.
There is hardly anything else which stresses process creation more
than shell scripting.
Doesn't Android fork off new applications from a zygote process? Then
the binding overhead would be incurred only once, and BIND_NOW would
even reduce footprint slightly (because the GOT is no longer dirtied in
the child processes).
More information about the Binutils