PowerPC PLT speculative execution barriers
Carlos O'Donell
carlos@redhat.com
Fri Jan 19 23:11:00 GMT 2018
On 01/19/2018 04:01 AM, Alan Modra wrote:
> On Fri, Jan 19, 2018 at 12:00:54AM -0800, Carlos O'Donell wrote:
>> On 01/17/2018 12:19 AM, Alan Modra wrote:
>>> Spectre variant 2 mitigation for PowerPC and PowerPC64.
>>
>> This is a really terse description of something which is
>> quite complicated. Are you able to expand on this a bit and
>> talk about what the patch is actually doing or conversely
>> add more comments?
>
> Well, as the subject says, the patch adds speculative execution
> barriers in PLT call code. That is accomplished by deliberately
> mis-predicting the indirect jump, so as to make any processor
> speculative execution head off somewhere safe. As you might expect,
> this will slow things down, so it isn't something you would want to
> use in every application.
Thank you for expanding on that.
Just to be clear though, this is is a non-modular mitigation, a user
desiring to reach 100% coverage from Spectre Variant 2 would need to
compile the transitive closure of DT_NEEDED and this includes compiling
glibc with this option? So if you need 100% protection you would also
need to work with downstream distros to turn this on everywhere?
Have you tried recompiling part of a distribution with this patch?
Do you have any performance analysis numbers which you can share?
For example, such a change in glibc would require an objective discussion
on the performance impact (particularly given that other solutions might
also exist).
Have you considered a thunk that can be rewritten by the ld.so depending
on the CPU being used at runtime?
>> This appears to change the size of the PLT entries. What does
>> the final sequence look like? Does this have any knock-on
>> effects to disassemblers?
>
> objdump will show you the new sequences. Disassemblers are affected
> only in the synthetic symbols placed on plt code, and there we are no
> worse than we were before. ie. they aren't very useful in showing
> ppc64 plt code, or ppc32 pic. Also, gold generates ppc32 plt code in
> a different place to ld.bfd, so you don't get useful synthetic
> symbols in gold binaries. Use --emit-stub-syms.
OK.
>> gdb?
>
> Yes, gdb needs some changes.
OK. Are you aware of any tooling that this will impact?
--
Cheers,
Carlos.
More information about the Binutils
mailing list