From: Paul Durrant <xadimgnik@gmail.com>
To: "'Andrew Cooper'" <andrew.cooper3@citrix.com>,
"'Xen-devel'" <xen-devel@lists.xenproject.org>
Cc: "'Ian Jackson'" <Ian.Jackson@citrix.com>,
"'Jan Beulich'" <JBeulich@suse.com>, "'Wei Liu'" <wl@xen.org>,
"'Roger Pau Monné'" <roger.pau@citrix.com>
Subject: RE: [PATCH for-4.14 0/9] XSA-320 follow for IvyBridge
Date: Mon, 15 Jun 2020 18:04:25 +0100 [thread overview]
Message-ID: <003101d64337$06b202c0$14160840$@xen.org> (raw)
In-Reply-To: <20200615141532.1927-1-andrew.cooper3@citrix.com>
> -----Original Message-----
> From: Xen-devel <xen-devel-bounces@lists.xenproject.org> On Behalf Of Andrew Cooper
> Sent: 15 June 2020 15:15
> To: Xen-devel <xen-devel@lists.xenproject.org>
> Cc: Wei Liu <wl@xen.org>; Paul Durrant <paul@xen.org>; Andrew Cooper <andrew.cooper3@citrix.com>; Jan
> Beulich <JBeulich@suse.com>; Ian Jackson <Ian.Jackson@citrix.com>; Roger Pau Monné
> <roger.pau@citrix.com>
> Subject: [PATCH for-4.14 0/9] XSA-320 follow for IvyBridge
>
> This is some work in light of IvyBridge not gaining microcode to combat SRBDS
> / XSA-320. It is a mix of some work I'd planned for 4.15, and some patches
> posted already and delayed due to dependence's I'd discovered after-the-fact.
>
> This provides a more user-friendly way of making IvyBridge safe by default
> without encountering migration incompatibilities.
>
> In terms of functionality, it finishes the "fresh boot" vs "migrate/restore
> from pre-4.14" split in the libxc CPUID logic, and uses this to let us safely
> hide features by default without breaking the "divine what a guest may have
> seen previously" logic on migrate.
>
> On top of that, we hide RDRAND by default to mitigate XSA-320.
>
> Additionally, take the opportunity of finally getting this logic working to
> hide MPX by default (as posted previously), due to upcoming Intel timelines.
>
> Request for 4.14. The IvyBridge angle only became apparent after the public
> embargo on Tue 9th. Otherwise, I would have made a concerted effort to get
> this logic sorted sooner and/or part of XSA-320 itself.
>
> Strictly speaking, patches 1-4 aren't necessary, but without them the logic is
> very confusing to follow, particularly the reasoning about the safely of later
> changes. As it is a simple set of transforms, we're better with them than
> without.
>
> Also, the MPX patch isn't related to the RDRAND issue, but I was planning to
> get it into 4.14 already, until realising that the migration path was broken.
> Now that the path is fixed for the RDRAND issue, include the MPX patch as it
> pertains to future hardware compatibility (and would be backported to 4.14.1
> if it misses 4.14.0).
>
Fair enough. Once the series has all the requisite maintainer acks then I'll release-ack it.
Paul
> Andrew Cooper (9):
> tools/libx[cl]: Introduce struct xc_xend_cpuid for xc_cpuid_set()
> tests/cpu-policy: Confirm that CPUID serialisation is sorted
> tools/libx[cl]: Move processing loop down into xc_cpuid_set()
> tools/libx[cl]: Merge xc_cpuid_set() into xc_cpuid_apply_policy()
> tools/libx[cl]: Plumb bool restore down into xc_cpuid_apply_policy()
> x86/gen-cpuid: Distinguish default vs max in feature annotations
> x86/hvm: Disable MPX by default
> x86/cpuid: Introduce missing feature adjustment in calculate_pv_def_policy()
> x86/spec-ctrl: Hide RDRAND by default on IvyBridge
>
> docs/misc/xen-command-line.pandoc | 20 ++-
> tools/libxc/include/xenctrl.h | 42 ++++-
> tools/libxc/xc_cpuid_x86.c | 239 ++++++++++++++++------------
> tools/libxl/libxl.h | 8 +-
> tools/libxl/libxl_cpuid.c | 17 +-
> tools/libxl/libxl_create.c | 2 +-
> tools/libxl/libxl_dom.c | 2 +-
> tools/libxl/libxl_internal.h | 12 +-
> tools/libxl/libxl_nocpuid.c | 2 +-
> tools/tests/cpu-policy/test-cpu-policy.c | 49 +++++-
> xen/arch/x86/cpuid.c | 23 +++
> xen/include/public/arch-x86/cpufeatureset.h | 4 +-
> xen/tools/gen-cpuid.py | 18 +--
> 13 files changed, 278 insertions(+), 160 deletions(-)
>
> --
> 2.11.0
>
next prev parent reply other threads:[~2020-06-15 17:04 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-15 14:15 [PATCH for-4.14 0/9] XSA-320 follow for IvyBridge Andrew Cooper
2020-06-15 14:15 ` [PATCH 1/9] tools/libx[cl]: Introduce struct xc_xend_cpuid for xc_cpuid_set() Andrew Cooper
2020-06-15 14:51 ` Ian Jackson
2020-06-15 14:15 ` [PATCH 2/9] tests/cpu-policy: Confirm that CPUID serialisation is sorted Andrew Cooper
2020-06-15 14:52 ` Ian Jackson
2020-06-15 15:00 ` Andrew Cooper
2020-06-15 15:34 ` Ian Jackson
2020-06-15 16:12 ` Andrew Cooper
2020-06-16 6:51 ` Jan Beulich
2020-06-16 9:01 ` Jan Beulich
2020-06-15 14:15 ` [PATCH 3/9] tools/libx[cl]: Move processing loop down into xc_cpuid_set() Andrew Cooper
2020-06-15 14:54 ` Ian Jackson
2020-06-16 9:16 ` Jan Beulich
2020-06-16 15:58 ` Andrew Cooper
2020-06-15 14:15 ` [PATCH 4/9] tools/libx[cl]: Merge xc_cpuid_set() into xc_cpuid_apply_policy() Andrew Cooper
2020-06-15 14:55 ` Ian Jackson
2020-06-15 14:15 ` [PATCH 5/9] tools/libx[cl]: Plumb bool restore down " Andrew Cooper
2020-06-15 14:55 ` Ian Jackson
2020-06-15 14:15 ` [PATCH 6/9] x86/gen-cpuid: Distinguish default vs max in feature annotations Andrew Cooper
2020-06-15 14:15 ` [PATCH 7/9] x86/hvm: Disable MPX by default Andrew Cooper
2020-06-16 9:33 ` Jan Beulich
2020-06-16 16:15 ` Andrew Cooper
2020-06-17 10:32 ` Jan Beulich
2020-06-17 11:16 ` Andrew Cooper
2020-06-17 11:24 ` Jan Beulich
2020-06-17 11:28 ` Andrew Cooper
2020-06-17 11:41 ` Jan Beulich
2020-06-17 11:47 ` Andrew Cooper
2020-06-15 14:15 ` [PATCH 8/9] x86/cpuid: Introduce missing feature adjustment in calculate_pv_def_policy() Andrew Cooper
2020-06-16 9:40 ` Jan Beulich
2020-06-16 16:17 ` Andrew Cooper
2020-06-15 14:15 ` [PATCH 9/9] x86/spec-ctrl: Hide RDRAND by default on IvyBridge Andrew Cooper
2020-06-16 10:00 ` Jan Beulich
2020-06-16 16:26 ` Andrew Cooper
2020-06-17 10:39 ` Jan Beulich
2020-06-17 11:21 ` Andrew Cooper
2020-06-15 17:04 ` Paul Durrant [this message]
2020-06-17 12:46 ` [PATCH for-4.14 0/9] XSA-320 follow for IvyBridge Paul Durrant
2020-06-18 7:18 ` Jan Beulich
2020-06-18 9:37 ` Andrew Cooper
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='003101d64337$06b202c0$14160840$@xen.org' \
--to=xadimgnik@gmail.com \
--cc=Ian.Jackson@citrix.com \
--cc=JBeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=paul@xen.org \
--cc=roger.pau@citrix.com \
--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 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 NNTP newsgroup(s).