This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: PATCH: Check GLIBC_IFUNC to enable/disable ifunc features
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Szabolcs Nagy <szabolcs dot nagy at arm dot com>
- Cc: "Carlos O'Donell" <carlos at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>, Siddhesh Poyarekar <sid at reserved-bit dot com>, nd <nd at arm dot com>
- Date: Thu, 30 Jun 2016 09:06:31 -0700
- Subject: Re: PATCH: Check GLIBC_IFUNC to enable/disable ifunc features
- Authentication-results: sourceware.org; auth=none
- References: <CAMe9rOq1+_rMbs1mt3=Md=Wx=7ZxUbD+BhOx-qrO5TBRBrRLww at mail dot gmail dot com> <20160630013716 dot GY4685 at vapier dot lan> <CAMe9rOrgshV6t5quE01r_oc91ps0JJ7fYfAC=MuQOs96qNv1uQ at mail dot gmail dot com> <57752F1B dot 7010809 at arm dot com>
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.