public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Florian Weimer <fweimer@redhat.com>
To: Peter Bergner <bergner@linux.ibm.com>
Cc: Richard Biener <rguenther@suse.de>,
	 "Richard Earnshaw \(lists\)" <Richard.Earnshaw@arm.com>,
	 gcc@gcc.gnu.org,
	 Tulio Magno Quites Machado Filho <tuliom@linux.ibm.com>
Subject: Re: Spectre V1 diagnostic / mitigation
Date: Wed, 19 Dec 2018 15:44:00 -0000	[thread overview]
Message-ID: <87bm5hv7wm.fsf@oldenburg2.str.redhat.com> (raw)
In-Reply-To: <48d6ff5c-5999-0a13-7646-fbdbdf203048@linux.ibm.com> (Peter	Bergner's message of "Wed, 19 Dec 2018 08:19:23 -0600")

* Peter Bergner:

> On 12/19/18 7:59 AM, Florian Weimer wrote:
>> * Richard Biener:
>> 
>>> Sure, if we'd ever deploy this in production placing this in the
>>> TCB for glibc targets might be beneifical.  But as said the
>>> current implementation was just an experiment intended to be
>>> maximum portable.  I suppose the dynamic loader takes care
>>> of initializing the TCB data?
>> 
>> Yes, the dynamic linker will initialize it.  If you need 100% reliable
>> initialization with something that is not zero, it's going to be tricky
>> though.  Initial-exec TLS memory has this covered, but in the TCB, we
>> only have zeroed-out reservations today.
>
> We have non-zero initialized TCB entries on powerpc*-linux which are used
> for the GCC __builtin_cpu_is() and __builtin_cpu_supports() builtin
> functions.  Tulio would know the magic that was used to get them setup.

Yes, there's a special symbol, __parse_hwcap_and_convert_at_platform, to
verify that the dynamic linker sets up the TCB as required.  This way,
binaries which need the feature will fail to run on older loaders.  This
is why I said it's a bit tricky to implement this.  It's even more
complicated if you want to backport this into released glibcs, where we
normally do not accept ABI changes (not even ABI additions).

Thanks,
Florian

  reply	other threads:[~2018-12-19 15:44 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-18 15:37 Richard Biener
2018-12-18 16:17 ` Jeff Law
2018-12-19 11:16   ` Richard Biener
2018-12-18 16:48 ` Richard Earnshaw (lists)
2018-12-19 11:25   ` Richard Biener
2018-12-19 11:34     ` Florian Weimer
2018-12-19 11:51       ` Richard Biener
2018-12-19 13:35         ` Florian Weimer
2018-12-19 13:49           ` Richard Biener
2018-12-19 14:01             ` Florian Weimer
2018-12-19 14:19               ` Peter Bergner
2018-12-19 15:44                 ` Florian Weimer [this message]
2018-12-19 17:17                   ` Richard Biener
2018-12-19 17:25                     ` Richard Earnshaw (lists)
2018-12-19 17:29                       ` Richard Biener
2018-12-19 15:42     ` Richard Earnshaw (lists)
2018-12-19 17:20       ` Richard Biener

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=87bm5hv7wm.fsf@oldenburg2.str.redhat.com \
    --to=fweimer@redhat.com \
    --cc=Richard.Earnshaw@arm.com \
    --cc=bergner@linux.ibm.com \
    --cc=gcc@gcc.gnu.org \
    --cc=rguenther@suse.de \
    --cc=tuliom@linux.ibm.com \
    /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).