Re: [Xen-devel] XSA-60 solutions

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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.

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