From: Juergen Gross <jgross@suse.com>
To: Borislav Petkov <bp@alien8.de>
Cc: x86@kernel.org, linux-kernel@vger.kernel.org, mingo@redhat.com,
hpa@zytor.com, xen-devel@lists.xenproject.org,
boris.ostrovsky@oracle.com, tglx@linutronix.de
Subject: Re: [PATCH] x86/amd: don't set X86_BUG_SYSRET_SS_ATTRS if forced to zero
Date: Wed, 26 Apr 2017 20:24:12 +0200 [thread overview]
Message-ID: <88dfeccc-61e9-20a7-e188-c3e5cb0f55d3__13917.002947028$1493231103$gmane$org@suse.com> (raw)
In-Reply-To: <20170426063556.vc2zmns3uscubuim@pd.tnic>
On 26/04/17 08:35, Borislav Petkov wrote:
> On Wed, Apr 26, 2017 at 06:45:42AM +0200, Juergen Gross wrote:
>> The really clean solution would be to add this test to set_cpu_bug()
>
> No, the really clean solution is to set it once and not play toggle
> games.
>
>> This would work. OTOH I'd prefer to test whether the bit should be
>> forced to remain zero than use the knowledge _who_ is trying to force
>> it.
>
> Because we're in the business of investigating who did?
>
> Nah, we should set it or clear it once and not do funky toggle games.
> Especially if in the future something else changes and timing windows
> grow and we refactor stuff and yadda yadda...
So what else is my patch doing? It is avoiding to set the bit in case
somebody (i.e. Xen) was forcing it to remain zero.
I'm not feeling strong about it. So if you want to test for
X86_FEATURE_XENPV to avoid setting X86_BUG_SYSRET_SS_ATTRS I'm fine
with it.
Will send V2 with that change.
Juergen
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
next prev parent reply other threads:[~2017-04-26 18:24 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-25 18:00 [PATCH] x86/amd: don't set X86_BUG_SYSRET_SS_ATTRS if forced to zero Juergen Gross
2017-04-25 18:24 ` Borislav Petkov
2017-04-25 18:24 ` Borislav Petkov
2017-04-25 18:34 ` Juergen Gross
2017-04-25 19:18 ` Borislav Petkov
2017-04-25 20:17 ` [Xen-devel] " Andrew Cooper
2017-04-25 20:27 ` Borislav Petkov
2017-04-25 20:27 ` [Xen-devel] " Borislav Petkov
2017-04-25 20:17 ` Andrew Cooper
2017-04-26 4:45 ` Juergen Gross
2017-04-26 6:35 ` Borislav Petkov
2017-04-26 6:35 ` Borislav Petkov
2017-04-26 18:24 ` Juergen Gross [this message]
2017-04-26 18:24 ` Juergen Gross
2017-04-26 22:04 ` Borislav Petkov
2017-04-26 22:04 ` Borislav Petkov
2017-04-27 4:44 ` Juergen Gross
2017-04-27 4:44 ` Juergen Gross
2017-04-26 4:45 ` Juergen Gross
2017-04-25 19:18 ` Borislav Petkov
2017-04-25 18:34 ` Juergen Gross
2017-04-25 18:00 Juergen Gross
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='88dfeccc-61e9-20a7-e188-c3e5cb0f55d3__13917.002947028$1493231103$gmane$org@suse.com' \
--to=jgross@suse.com \
--cc=boris.ostrovsky@oracle.com \
--cc=bp@alien8.de \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.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.