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: PowerPC PLT speculative execution barriers


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.


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