[PATCH for-4.14 0/9] XSA-320 follow for IvyBridge

Andrew Cooper posted 9 patches 3 years, 9 months ago
Patches applied successfully (tree, apply log)
git fetch https://github.com/patchew-project/xen tags/patchew/20200615141532.1927-1-andrew.cooper3@citrix.com
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(-)
[PATCH for-4.14 0/9] XSA-320 follow for IvyBridge
Posted by Andrew Cooper 3 years, 9 months ago
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).

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


RE: [PATCH for-4.14 0/9] XSA-320 follow for IvyBridge
Posted by Paul Durrant 3 years, 9 months ago
> -----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
> 



RE: [PATCH for-4.14 0/9] XSA-320 follow for IvyBridge
Posted by Paul Durrant 3 years, 9 months ago
> -----Original Message-----
> From: Paul Durrant <xadimgnik@gmail.com>
> Sent: 15 June 2020 18:04
> To: 'Andrew Cooper' <andrew.cooper3@citrix.com>; 'Xen-devel' <xen-devel@lists.xenproject.org>
> Cc: 'Wei Liu' <wl@xen.org>; 'Jan Beulich' <JBeulich@suse.com>; 'Ian Jackson' <Ian.Jackson@citrix.com>;
> 'Roger Pau Monné' <roger.pau@citrix.com>
> Subject: RE: [PATCH for-4.14 0/9] XSA-320 follow for IvyBridge
> 
> > -----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.
> 

I believe all acks are now place so the series is...

Release-acked-by: Paul Durrant <paul@xen.org>




Re: [PATCH for-4.14 0/9] XSA-320 follow for IvyBridge
Posted by Jan Beulich 3 years, 9 months ago
On 15.06.2020 16:15, Andrew Cooper wrote:
> 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).

Just to be sure - it is my understanding that none of this can sensibly
be backported, even if it was nice for us to take care of the IvyBridge
situation on older trees as well.

Jan

Re: [PATCH for-4.14 0/9] XSA-320 follow for IvyBridge
Posted by Andrew Cooper 3 years, 9 months ago
On 18/06/2020 08:18, Jan Beulich wrote:
> On 15.06.2020 16:15, Andrew Cooper wrote:
>> 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).
> Just to be sure - it is my understanding that none of this can sensibly
> be backported, even if it was nice for us to take care of the IvyBridge
> situation on older trees as well.

Correct.  Much as I'd like this to be backported, it depends on
approximately all the toolstack work I got complete in 4.14.

The changes to xc_apply_cpuid_policy() are only safe because the
behaviour of 4.13 is known (and fixed), and that all versions of Xen
we've made "breaking" default changes have the boot CPUID settings
properly in the migrate stream.

~Andrew