Re: Updated version of RD/WR FS/GS BASE patchkit

[Andy Lutomirski]

On Mon, Mar 21, 2016 at 3:11 PM, Andi Kleen <andi@xxxxxxxxxxxxxx> wrote:
>> So a patchset to enable these asinine new instructions needs to take
>> this into account, and the ABI issue needs to be addressed, even if
>
> What's the ABI issue?
>
> AFAIK we're perfectly consistent.
>
>> the answer is that the proposed code is fine.
>>
>> (Also, the existing code is fscked up.  Guess what xor %eax, %eax; mov
>> %ax, %gs does to the base on AMD?  The existing code is *wrong*, and I
>> don't want to see it get wronger.)
>
> I have no idea, but changing it is definitely not in scope for my patches.
>
>>
>> And no, I don't really care about programs detecting context switches.
>> I do, however, care about allowing non-determinism in things that
>> ought to behave deterministically.  Writing a nonzero value to %gs and
>> then doing WRGSBASE is something that user code will be able to do
>> whether we like it or not, some shitty threading library is likely to
>> do this just to spite us, the the kernel needs to do *something* when
>> this happens.
>
> They will quickly notice it if there is a problem, so I don't think
> we need to worry about that.

Really?

Imagine that some brilliant lightweight threading library does:

 - set GS to nonzero (by whatever means -- arch_prctl(ARCH_SET_GS,
whatever) on a pre-IVB host followed by migration, some modify_ldt
garbage, simple bloody-mindedness, whatever);
 - WRGSBASE
 - Use GS for a bit

This will work most of the time until it gets unlucky with preemption.
And yes, runtime library authors really do mess up in amazing ways.

It's an issue.  It needs conscious design.