This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On Mon, Jan 8, 2018 at 10:40 AM, Florian Weimer <fweimer@redhat.com> wrote:
> On 01/08/2018 07:35 PM, Sriraman Tallam wrote:
>>
>> On Mon, Jan 8, 2018 at 10:23 AM, Florian Weimer <fweimer@redhat.com>
>> 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
>>> equation.
>>
>>
>> * Yes, you are right and we did work to patch LLVM with this,
>> https://reviews.llvm.org/D41723
>> * 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).

Not sure, but I was referring to Chrome OS.  I assumed they were using
lazy binding for start-up time but I checked with Rahul right now who
confirms that is not the case so this is my wrong assumption.

Thanks'
Sri

>
> Thanks,
> Florian


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]