Re: [Xen-devel] [PATCH 3/3 V3] XSA-60 security hole: cr0.cd handling

[DuanZhenzhong <zhenzhong.duan@xxxxxxxxxx>]

Jan Beulich wrote:
> > > > On 21.10.13 at 17:55, "Liu, Jinsong" <jinsong.liu@xxxxxxxxx> wrote:
> > > >         
> > From 4ff1e2955f67954e60562b29a00adea89e5b93ae Mon Sep 17 00:00:00 2001
> > From: Liu Jinsong <jinsong.liu@xxxxxxxxx>
> > Date: Thu, 17 Oct 2013 05:49:23 +0800
> > Subject: [PATCH 3/3 V3] XSA-60 security hole: cr0.cd handling
> >
> > This patch solves XSA-60 security hole:
> > 1. For guest w/o VT-d, and for guest with VT-d but snooped, Xen need
> > do nothing, since hardware snoop mechanism has ensured cache coherency.
> >
> > 2. For guest with VT-d but non-snooped, cache coherency can not be
> > guaranteed by h/w snoop, therefore it need emulate UC type to guest:
> > 2.1). if it works w/ Intel EPT, set guest IA32_PAT fields as UC so that
> > guest memory type are all UC.
> > 2.2). if it works w/ shadow, drop all shadows so that any new ones would
> > be created on demand w/ UC.
> >
> > This patch also fix a bug of shadow cr0.cd setting. Current shadow has a
> > small window between cache flush and TLB invalidation, resulting in possilbe
> > cache pollution. This patch pause vcpus so that no vcpus context involved
> > into the window. 
> >
> > Signed-off-by: Liu Jinsong <jinsong.liu@xxxxxxxxx>
> >     
> This looks fine to me now, but will need acks/reviews at least from
> - Keir (whose blessing of the pausing construct I'd like to have even
>   if this didn't involve changing non-x86 files)
> - one of the VMX maintainers
> - one or both of Tim and Andrew
>
> And of course I'd really appreciate if Oracle could arrange for
> testing this, to confirm their performance problem is also gone with
> this.
>   
I am try finding an env to test it. I'll reply after test.

zduan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel