Re: PING: [PATCH] i386: Add TARGET_INDIRECT_BRANCH_REGISTER

[Jeff Law <law at redhat dot com>]

On 02/28/2018 02:39 AM, Steve Beattie wrote:
> Hi Jeff,
> 
> On Thu, Feb 22, 2018 at 10:10:13AM -0700, Jeff Law wrote:
>> A few notes.
>>
>> 1. It's not even clear at this time that retpolining user space binaries
>> makes any sense at all.   SO before doing anything to make this easier
>> I'd like to see a justification for why it's really needed.
> 
> Do you have a reference that gives evidence that retpolining user
> space is not needed or not preferred for x86? Everything that I've
> seen has suggested user space to user space attacks are possible,
> if difficult. And it does not seem likely that microcode updates will
> occur for all processor generations out there.
No reference, but that's general conclusion we've come to internally
with input from Intel.

Essentially you use the newly exposed capabilities from the microcode
updates to flush the state of the indirect predictor at context switch
time.  Combine that with the microcode change to stop sharing indirect
branch prediction state between SMT threads.

I'm being a bit imprecise, but that's the gist.


> 
>> 2. On the other hand, the existing thunk options do make it easier to
>> test independent of hte kernel.  ie, I can turn on inline thunks by
>> default and test things in user space (ie, do thunks generally work
>> properly).
> 
> If thunk-extern is to be the only maintained option, and its deemed
> sensible for user space in at least some situations, is there a
> preferred location for the thunks to end up?
Ideally you'd have one set of thunks per DSO.  Otherwise you end up
doing an indirect branch for the cross-DSO call to get to the thunk
which largely defeats the purpose of the thunks to begin with.


> 
> (I ask these questions because you can already find individual users
> recompiling apps important to them with retpoline options, and there
> is pressure (with associated deadlines) in some quarters to rebuild
> vast tracts of user space with retpolines for x86.)
I know.  I've given up trying to educate all of them.  I expected all
along that well intentioned, but ultimately clueless, folks would start
doing this kind of thing.

jeff

Attachment: signature.asc
Description: OpenPGP digital signature