This is the mail archive of the
mailing list for the glibc project.
Re: [PATCHv4 0/2] tunables for glibc
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Siddhesh Poyarekar <siddhesh at sourceware dot org>
- Cc: GNU C Library <libc-alpha at sourceware dot org>, "Carlos O'Donell" <carlos at redhat dot com>, Florian Weimer <fweimer at redhat dot com>
- Date: Wed, 7 Sep 2016 07:44:50 -0700
- Subject: Re: [PATCHv4 0/2] tunables for glibc
- Authentication-results: sourceware.org; auth=none
- References: <firstname.lastname@example.org> <CAMe9rOqdSjVL0PLyLMQ=Hki4=ms1iygWi+j9YNtHpmvO9TVXMg@mail.gmail.com> <email@example.com>
On Tue, Sep 6, 2016 at 11:25 PM, Siddhesh Poyarekar
> On Wednesday 24 August 2016 12:37 AM, H.J. Lu wrote:
>> It needs to be called before init_cpu_features on x86.
> I've been thinking about this and it seems that init_cpu_features is
> called too early and I can't call __tunables_init any earlier without
> impacting what it can read, i.e. __libc_enable_secure for example.
> So one approach to solving this could be to find a place in init-first
> where init_cpu_features can be called early enough and still later than
> __tunables_init. I haven't done a thorough analysis but it seems it can
> be done.
> However a cleaner approach seems to me to be to keep the cpu features
> stuff separate from the overriding and then modify the ifunc resolvers
> to use the overrides if necessary. That is, let the cpu features show
> what the cpu is actually capable of and have a separate overriding
> structure that is initialized later (via __init_tunables or before ifunc
> resolution) and used when necessary, i.e. not used for AT_SECURE
> executables or any other condition that may arise in future.
The whole point of cpu features is it is initialized as early as possible
so that it can be used for ifunc. I don't think __init_tunables is suitable
for ifunc, which doesn't have any security implications on x86.