This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc 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: PATCH: Check GLIBC_IFUNC to enable/disable ifunc features


On Thu, Jun 30, 2016 at 7:39 AM, Szabolcs Nagy <szabolcs.nagy@arm.com> wrote:
> On 30/06/16 03:56, H.J. Lu wrote:
>> The environment
>> variable, GLIBC_IFUNC=xxx=0:yyy=1:zzz=0...., can be used to enable
>> CPU/ARCH feature yyy, disable CPU/ARCH feature yyy and zzz, where the
>> feature name is case-sensitive and has to match the ones in
>> cpu-features.h.  It can be used by glibc developers to override the
>> IFUNC selection to improve performance for a particular workload or
>> tune for a new processor.
>>
>
> since it is for glibc devs only is it expected to be
> stable across glibc versions?

SInce INFUNC implementation changes over time, it won't be
stable.

> may be the env var name could reflect that it is not
> a public api.

GLIBC_IFUNC is private.

>> Since all CPU/ARCH features are hardware optimizations without security
>> implication, except for Prefer_MAP_32BIT_EXEC, which can only be disabled,
>> we check GLIBC_IFUNC for programs, including set*id ones.
>>
>
> i think it can have security implications, but probably not significant.

If there are security implications in IFUNC implementation,
it is a bug in IFUNC implementation.

>> NOTE: the IFUNC selection may change over time.  Please check all
>> multiarch implementations when experimenting.
>>
>
>> +init_cpu_features (struct cpu_features *cpu_features, char **env)
> ...
>> +  while (*env != NULL)
>> +    {
>> +      const char *p, *end;
>> +      size_t len = sizeof ("GLIBC_IFUNC=");
>> +
>> +      end = *env;
>> +      for (p = end; *p != '\0'; p++)
>> +     if (--len == 0 && equal (end, "GLIBC_IFUNC=", 12))
>> +       {
>> +         len = strlen (p);
>
> is this x86_64 only?

No.  It is in sysdeps/x86/cpu-features.c, which is shared by
i386 and x86_64.

> how can strlen work before ifunc is done?
> (i think strlen is ifunc resolved on i386)
>
> i know ld.so is careful about this, but i think
> with static linking ifunc resolved functions
> should not be called before apply_irel is done
>

I will remove strlen to be on the safe side.

-- 
H.J.


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