public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: "H.J. Lu" <hjl.tools@gmail.com>
To: Siddhesh Poyarekar <siddhesh@sourceware.org>
Cc: GNU C Library <libc-alpha@sourceware.org>,
	"Carlos O'Donell" <carlos@redhat.com>,
	 Florian Weimer <fweimer@redhat.com>
Subject: Re: [PATCHv4 0/2] tunables for glibc
Date: Wed, 07 Sep 2016 14:45:00 -0000	[thread overview]
Message-ID: <CAMe9rOqTMp=4hdpEja3+mwAh3Rz_hpoBq_vk-ESGqtjURtZQng@mail.gmail.com> (raw)
In-Reply-To: <9e066dc5-fe7e-5925-0e43-f65fb4fa41f6@sourceware.org>

On Tue, Sep 6, 2016 at 11:25 PM, Siddhesh Poyarekar
<siddhesh@sourceware.org> wrote:
> 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.

-- 
H.J.

  reply	other threads:[~2016-09-07 14:45 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-15 20:05 Siddhesh Poyarekar
2016-08-15 20:05 ` [PATCH 2/2] Initialize tunable list with the GLIBC_TUNABLES environment variable Siddhesh Poyarekar
2016-08-15 20:05 ` [PATCH 1/2] Add framework for tunables Siddhesh Poyarekar
2016-08-23  8:08 ` [PING][PATCHv4 0/2] tunables for glibc Siddhesh Poyarekar
2016-08-23 19:08 ` [PATCHv4 " H.J. Lu
2016-09-07  6:25   ` Siddhesh Poyarekar
2016-09-07 14:45     ` H.J. Lu [this message]
2016-09-07 14:51       ` Florian Weimer
2016-09-10 15:30       ` Siddhesh Poyarekar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAMe9rOqTMp=4hdpEja3+mwAh3Rz_hpoBq_vk-ESGqtjURtZQng@mail.gmail.com' \
    --to=hjl.tools@gmail.com \
    --cc=carlos@redhat.com \
    --cc=fweimer@redhat.com \
    --cc=libc-alpha@sourceware.org \
    --cc=siddhesh@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).