[PATCH] elf: Do not read hwcaps from the vDSO in ld.so

[Adhemerval Zanella]

On 26/05/2020 10:47, Florian Weimer wrote:
> * Adhemerval Zanella via Libc-alpha:
> 
>> On 19/05/2020 14:06, Florian Weimer via Libc-alpha wrote:
>>> This was only ever used for the "nosegneg" flag.  This approach for
>>> passing hardware capability information creates a subtle dependency
>>> between the kernel and userspace, and ld.so.cache contents.  It seems
>>> inappropriate for toady, where people expect to be able to run
>>> system images which very different kernel versions.
>>
>> I agree that such dependency is not suitable for current practices and
>> environment where glibc is used. From digging the history of "nosegneg" 
>> flag it seemed a hack around some issue or limitation from XEN kernels. 
>> Do you have more information of what exactly nosegneg tried to prevent?
> 
> It used to select a glibc built with -mno-tls-direct-seg-refs.  Not
> doing complicated address calculations in segment-based accesses somehow
> simplified things for Xen with paravirtualization.  Our notes indicate
> that this was caused by negative segment-relative references, so
> -mno-tls-direct-seg-refs was likely too big a hammer.

Is it still a valid build option for either glibc or programs targetting
glibc?

> 
> In practice, this matters only in very few places in glibc where we
> access TLS variables that are *not* in the TCB or the thread descriptor,
> because those are at positive offsets.
> 
> An example would look like this:
> 
> Dump of assembler code for function __syscall_error:
>    0x0001f090 <+0>:	endbr32 
>    0x0001f094 <+4>:	call   0x132b41 <__x86.get_pc_thunk.dx>
>    0x0001f099 <+9>:	add    $0x18cd8b,%edx
>    0x0001f09f <+15>:	neg    %eax
>    0x0001f0a1 <+17>:	mov    0xdc(%edx),%edx
>    0x0001f0a7 <+23>:	mov    %eax,%gs:(%edx)
>    0x0001f0aa <+26>:	mov    $0xffffffff,%eax
>    0x0001f0af <+31>:	ret    
> 
> At the point of the %gs-relative load, %edx is negative because that's
> where the TLS variables are.
> 
> With a little bit of care, the performance benefits would likely have
> been achievable without a separate glibc build.

Thanks for the explanation, I tried to dig this rationale without
much success.

> 
>> LGTM, thanks.
>>
>> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
> 
> Thanks.
> 
> Florian
>