All of lore.kernel.org
 help / color / mirror / Atom feed
From: Norbert Manthey <nmanthey@amazon.de>
To: Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Juergen Gross <jgross@suse.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>, Wei Liu <wl@xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Jackson <ian.jackson@citrix.com>,
	Xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH v3 2/7] xen/nospec: Use always_inline to fix code gen for evaluate_nospec
Date: Fri, 25 Oct 2019 23:56:50 +0200	[thread overview]
Message-ID: <5b6b2cd3-b8a5-7697-e6f4-f7c337242276@amazon.de> (raw)
In-Reply-To: <477a6513-0caf-fc4a-21cf-a3a101b6c5ca@suse.com>

On 10/25/19 17:40, Jan Beulich wrote:
> On 25.10.2019 17:27, Andrew Cooper wrote:
>> On 25/10/2019 13:34, Jan Beulich wrote:
>>> On 25.10.2019 14:10, Andrew Cooper wrote:
>>>> The two choices to unblock 4.13 are this patch, or the previous version
>>>> which made CONFIG_HARDEN_BRANCH depend on BROKEN, which was even more
>>>> disliked.
>>> Option 3 is to have just the config option, for people to turn this
>>> off if they feel like doing so.
>> Yes, but no.  A facade of security is worse than no security, and I
>> don't consider doing that an acceptable solution in this case.
> But I thought we all agree that this is something that's presumably
> going to remain incomplete (as in not provably complete) altogether
> anyway. It's just that without the change here it's far more
> incomplete then with it.
>
> In any event I think we should (also) have an opinion from the people
> who had originally contributed this logic. You didn't Cc anyone of
> them; I've added at least Norbert now.

Thanks for adding me. I had a quick look into the discussion. Only
making adding lfence statements around conditionals depending on config
BROKEN does not help, as it would still need to be always_inline to work
as expected, correct? Hence, in my opinion, this patch does the right
thing to benefit from the lfences that are placed after evaluation
conditionals.

From a "is this lfence required" point of view, we have been able to
trigger loads where the lfence has not been present, and could not
reproduce any more once we added the lfence statements on both branches
after the conditional jump.

Best,
Norbert

>
> Jan



Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Ralf Herbrich
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

  reply	other threads:[~2019-10-25 21:57 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-23 13:58 [Xen-devel] [PATCH for-4.13 v3 0/7] Unbreak evaluate_nospec() and livepatching Andrew Cooper
2019-10-23 13:58 ` [Xen-devel] [PATCH v3 1/7] x86/nospec: Two trivial fixes Andrew Cooper
2019-10-23 14:03   ` Jan Beulich
2019-10-23 14:43   ` Jürgen Groß
2019-10-23 13:58 ` [Xen-devel] [PATCH v3 2/7] xen/nospec: Use always_inline to fix code gen for evaluate_nospec Andrew Cooper
2019-10-23 14:44   ` Jürgen Groß
2019-10-25 12:03   ` Jan Beulich
2019-10-25 12:10     ` Andrew Cooper
2019-10-25 12:34       ` Jan Beulich
2019-10-25 15:27         ` Andrew Cooper
2019-10-25 15:40           ` Jan Beulich
2019-10-25 21:56             ` Norbert Manthey [this message]
2019-10-28 17:05               ` Andrew Cooper
2019-10-29  8:25                 ` Norbert Manthey
2019-10-29 13:46                   ` Andrew Cooper
2019-10-29 14:03                     ` Jan Beulich
2019-10-29 14:16                       ` Andrew Cooper
2019-10-29 14:33                         ` Norbert Manthey
2019-10-29 16:53     ` Andrew Cooper
2019-10-30  8:33       ` Jan Beulich
2019-10-23 13:58 ` [Xen-devel] [PATCH v3 3/7] xen/nospec: Introduce CONFIG_SPECULATIVE_HARDEN_BRANCH Andrew Cooper
2019-10-23 14:45   ` Jürgen Groß
2019-10-25 12:04   ` Jan Beulich
2019-10-23 13:58 ` [Xen-devel] [PATCH v3 4/7] x86/nospec: Rename and rework l1tf-barrier as branch-harden Andrew Cooper
2019-10-23 14:43   ` Jürgen Groß
2019-10-25 12:09   ` Jan Beulich
2019-10-29 17:00     ` Andrew Cooper
2019-10-23 13:58 ` [Xen-devel] [PATCH v3 5/7] x86/livepatch: Fail the build if duplicate symbols exist Andrew Cooper
2019-10-23 14:46   ` Jürgen Groß
2019-10-23 16:14     ` Konrad Rzeszutek Wilk
2019-10-23 16:37   ` Ross Lagerwall
2019-10-24 12:03   ` Jan Beulich
2019-10-29 17:06     ` Andrew Cooper
2019-10-30  8:41       ` Jan Beulich
2019-10-30 10:37         ` Andrew Cooper
2019-10-30 11:21           ` Jan Beulich
2019-10-23 13:58 ` [Xen-devel] [PATCH for-next v3 6/7] x86/nospec: Move array_index_mask_nospec() into nospec.h Andrew Cooper
2019-10-25 12:10   ` Jan Beulich
2019-10-23 13:58 ` [Xen-devel] [PATCH v3 7/7] x86/nospec: Optimise array_index_mask_nospec() for power-of-2 arrays Andrew Cooper
2019-10-25 12:24   ` Jan Beulich
2019-10-25 12:58     ` Andrew Cooper
2019-10-25 13:25       ` Jan Beulich

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=5b6b2cd3-b8a5-7697-e6f4-f7c337242276@amazon.de \
    --to=nmanthey@amazon.de \
    --cc=George.Dunlap@eu.citrix.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=ian.jackson@citrix.com \
    --cc=jbeulich@suse.com \
    --cc=jgross@suse.com \
    --cc=julien@xen.org \
    --cc=konrad.wilk@oracle.com \
    --cc=sstabellini@kernel.org \
    --cc=wl@xen.org \
    --cc=xen-devel@lists.xenproject.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.