Re: -mno-tls-direct-seg-refs support in glibc for i386 PV Xen

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 27/05/2020 14:44, Samuel Thibault wrote:
> Hello,
>
> Andrew Cooper via Libc-alpha, le mer. 27 mai 2020 14:39:00 +0100, a ecrit:
>> Why does the MSB make any difference?  %gs still needs to remain intact
>> so the thread pointer can be pulled out, so there is nothing that Xen or
>> Linux can do in the way of lazy loading.
>>
>> Beyond that, its straight up segment base semantics in x86.  There will
>> be a 1-cycle AGU delay from a non-zero base, but that nothing to do with
>> Xen and applies to all segment based TLS accesses on x86, and you'll win
>> that back easily through reduced register pressure.
>>
>> Are there any further details on the perf problem claim?  I find it
>> suspicious.
> The concern is not about the indirection.
>
> The concern is that to keep safe from the guest, the hypervisor has to
> restrict the size of the segment, and thus negative offsets, used in the
> i386 TLS model, are rejected by the processor, and the hypervisor has to
> emulate these access, thus a high cost.

Oh, so the i386 TLS model relies on the calculation wrapping (modulo 4G)
when the segment limit is 4G, instead of taking a fault?

Intel states this is behaviour is implementation specific (SDM Vol3
5.3.1) and may fault, while AMD doesn't discuss it at all as far as I
can tell (APM Vol2 4.12 is the right section, but I can't see this
discussed).

While I can believe it probably works on every processor these days, it
does seem like dodgy ground to base an ABI on.

It also means that Xen isn't necessarily the only affected party.  I'm
pretty sure GRSecurity use reduced segment limits as well.

I also bet it doesn't work reliably under emulation.

~Andrew