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

[Paul Durrant <xadimgnik@xxxxxxxxx>]

> -----Original Message-----
> From: Paul Durrant <xadimgnik@xxxxxxxxx>
> Sent: 15 June 2020 18:04
> To: 'Andrew Cooper' <andrew.cooper3@xxxxxxxxxx>; 'Xen-devel' 
> <xen-devel@xxxxxxxxxxxxxxxxxxxx>
> Cc: 'Wei Liu' <wl@xxxxxxx>; 'Jan Beulich' <JBeulich@xxxxxxxx>; 'Ian Jackson' 
> <Ian.Jackson@xxxxxxxxxx>;
> 'Roger Pau Monné' <roger.pau@xxxxxxxxxx>
> Subject: RE: [PATCH for-4.14 0/9] XSA-320 follow for IvyBridge
> 
> > -----Original Message-----
> > From: Xen-devel <xen-devel-bounces@xxxxxxxxxxxxxxxxxxxx> On Behalf Of 
> > Andrew Cooper
> > Sent: 15 June 2020 15:15
> > To: Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
> > Cc: Wei Liu <wl@xxxxxxx>; Paul Durrant <paul@xxxxxxx>; Andrew Cooper 
> > <andrew.cooper3@xxxxxxxxxx>;
> Jan
> > Beulich <JBeulich@xxxxxxxx>; Ian Jackson <Ian.Jackson@xxxxxxxxxx>; Roger 
> > Pau Monné
> > <roger.pau@xxxxxxxxxx>
> > 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@xxxxxxx>