public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Steve Beattie <sbeattie@ubuntu.com>
To: Jeff Law <law@redhat.com>
Cc: Jan Hubicka <hubicka@ucw.cz>, "H.J. Lu" <hjl.tools@gmail.com>,
	GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: PING: [PATCH] i386: Add TARGET_INDIRECT_BRANCH_REGISTER
Date: Wed, 28 Feb 2018 09:39:00 -0000	[thread overview]
Message-ID: <20180228093926.GA19650@nxnw.org> (raw)
In-Reply-To: <c594d313-1401-54d3-42ff-efb64859e22e@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 1385 bytes --]

Hi Jeff,

On Thu, Feb 22, 2018 at 10:10:13AM -0700, Jeff Law wrote:
> A few notes.
> 
> 1. It's not even clear at this time that retpolining user space binaries
> makes any sense at all.   SO before doing anything to make this easier
> I'd like to see a justification for why it's really needed.

Do you have a reference that gives evidence that retpolining user
space is not needed or not preferred for x86? Everything that I've
seen has suggested user space to user space attacks are possible,
if difficult. And it does not seem likely that microcode updates will
occur for all processor generations out there.

> 2. On the other hand, the existing thunk options do make it easier to
> test independent of hte kernel.  ie, I can turn on inline thunks by
> default and test things in user space (ie, do thunks generally work
> properly).

If thunk-extern is to be the only maintained option, and its deemed
sensible for user space in at least some situations, is there a
preferred location for the thunks to end up?

(I ask these questions because you can already find individual users
recompiling apps important to them with retpoline options, and there
is pressure (with associated deadlines) in some quarters to rebuild
vast tracts of user space with retpolines for x86.)

Thanks.

-- 
Steve Beattie
<sbeattie@ubuntu.com>
http://NxNW.org/~steve/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  parent reply	other threads:[~2018-02-28  9:39 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-08 18:05 H.J. Lu
2018-02-22 14:29 ` Jan Hubicka
2018-02-22 14:34   ` H.J. Lu
2018-02-22 14:38     ` Jan Hubicka
2018-02-22 16:34       ` H.J. Lu
2018-02-22 17:10       ` Jeff Law
2018-02-22 17:33         ` H.J. Lu
2018-02-23 20:53           ` H.J. Lu
2018-02-28  9:39         ` Steve Beattie [this message]
2018-02-28 15:58           ` Jeff Law
2018-02-26 15:47       ` Jan Hubicka
2018-02-26 16:22         ` H.J. Lu
2018-02-26 16:54           ` Jan Hubicka
2018-02-27 12:49             ` H.J. Lu
2018-02-27 13:10               ` Jan Hubicka

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=20180228093926.GA19650@nxnw.org \
    --to=sbeattie@ubuntu.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=hjl.tools@gmail.com \
    --cc=hubicka@ucw.cz \
    --cc=law@redhat.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).