Re: [Xen-devel] XSA-60 solutions

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

Jan Beulich wrote:
>>>> On 07.10.13 at 16:29, "Liu, Jinsong" <jinsong.liu@xxxxxxxxx>
>>>> wrote: Any comments/suggestions? 
> 
> As pointed out in earlier private conversation, I think that the dual
> table approach would be preferable if it can be made work.

No, solution 2 has an important update compared with our private conversation 
before:
The old solution 2 is, Xen do nothing for guest cr0.cd setting.
The new solution 2 in this email is, Xen set IA32_PAT fields as UC when needed 
(that means, only when guest work with vt-d but vt-d non-snooped, since under 
this case h/w can not guarantee cache coherency), so that all guest memory type 
are UC. For other cases (when guest work w/o vt-d, and when guest work with 
vt-d but vt-d snooped), Xen can still do nothing for guest cr0.cd setting 
(since h/w has guaranteed cache coherency, otherwise Xen doesn't dare to do 
what it does now -- it set iPAT bit as 1, totally ignoring guest memory type 
point of view).

Compared with Dual-EPT solution, it's much simpler (only need IA32_PAT MSR 
emulation under rare case) and avoid the inconsistency issue between 2 EPT 
tables.

Thanks,
Jinsong

> 
> I'm surprised no-one from Oracle responded so far, as it was them
> originally having found the issue.
> 
> Jan
> 
>> Liu, Jinsong wrote:
>>> Liu, Jinsong wrote:
>>>> Hi, All
>>>> 
>>>> This email provides 2 solutions for XSA-60 issue found by Konrad
>>>> (refer attached email for XSA-60 please).
>>>> 
>>>> Basically it involves how to emulate guest setting cr0.cd. For
>>>> shadow, as Jan pointed out in earlier email Xen drop all shadows so
>>>> that any new ones would be created with UC memory type, _not_
>>>> involving iteration over the whole address space. For EPT,
>>>> currently Xen traverse all ept entries via problematic
>>>> set_uc_mode, resulting in DOS-like behavior, so this email focus
>>>> on Intel EPT case. 
>>>> 
>>>> Solution 1 is Dual-EPT tables: When guest setting cr0.cd trapped,
>>>> stop using normal EPT, switch to a temp EPT table and populate new
>>>> EPT entries w/ UC type on demand at later EPT violation. When guest
>>>> clearing cr0.cd, switch back to normal EPT. In this way, _no_
>>>> unbounded loop involved and hence security hole avoided.
>>>> 
>>>> Some concerns for Dual-EPT: the 1st concern comes from cachablity
>>>> confliction between guest and Xen memory type point of view, though
>>>> it also exists in current implementation. The 2nd concern comes
>>>> from Dual EPT tables inconsistency/sync issue: things become
>>>> complicated when p2m modifying, PoD populating, and super page
>>>> spliting, etc. 
>>>> 
>>>> Solution 2 is via PAT emulation: For guest w/o VT-d, and for guest
>>>> with VT-d but snooped, Xen need do nothing, just simply ignore
>>>> guest setting cr0.cd, since hardware snoop mechanism has ensured
>>>> cache coherency (under these cases currently Xen has set EPT iPAT
>>>> bit, ignore guest's memory type opinion); For guest with VT-d but
>>>> non-snooped, cache coherency can not be guaranteed by h/w snoop so
>>>> guest's memory type opinion must be considered (under this case Xen
>>>> set iPAT bit combining guest and host memory type opinion). Only
>>> 
>>> Sorry, under this case Xen _clear_ iPAT, combining guest and host
>>> memory type opinion. 
>>> 
>>> Thanks,
>>> Jinsong
>>> 
>>>> under this case PAT emulation need set all IA32_PAT fields as UC so
>>>> that guest memory type are all UC.
>>>> 
>>>> Concern for PAT solution still comes from cachablity confliction
>>>> between guest and Xen. 
>>>> 
>>>> Thoughts?
>>>> BTW, today is Chinese National day, I will have several days travel
>>>> with no email access, but your comments/suggestions are highly
>>>> appreciated and I will reply ASAP after I come back.
>>>> 
>>>> Thanks,
>>>> Jinsong


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