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

["Liu, Jinsong" <jinsong.liu@xxxxxxxxx>]

Jan Beulich wrote:
>>>> "Nakajima, Jun" <jun.nakajima@xxxxxxxxx> 10/23/13 6:29 PM >>>
>> On Tue, Oct 22, 2013 at 7:55 AM, Jan Beulich <JBeulich@xxxxxxxx>
>> 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.
>> 
>> Can you make sure that "setting guest IA32_PAT fields as UC" doesn't
>> have a conflict with the existing (other) settings done by the guest?
> 
> I don't think I understand the question, and I also don't think I'm
> the right addressee (I think you meant to send this to Jinsong and
> only Cc me). 
> 
> Jan

Maybe Jun's concern is 'guest PAT (real pat of vmcs which take effect, not 
nominal guest_pat) should be identical among all physical processors which run 
vcpus of that guest', am I right, Jun?

One thing I'm not sure is, per Intel SDM (8.7.4 of volume 3), the PAT MSR 
settings must be the same for all processors in a system. However, Xen 
obviously doesn't satisfy this requirement: PAT of the cpus running vmm context 
(50100070406) is not identical to PAT of the cpus running guest context (take 
rhel6.4 guest as example, it's 7010600070106) -- practically it works fine.


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