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

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

Jan Beulich wrote:
>>>> On 29.10.13 at 17:52, "Liu, Jinsong" <jinsong.liu@xxxxxxxxx> wrote:
>> Jan Beulich wrote:
>>> No - consider a VM exit while in this mode where, in order to
>>> process it, the hypervisor or service domain touch guest memory.
>>> Such touching will happen with caches being used, and hence
>>> unwritten data may be left in the caches when exiting back to the
>>> guest when there's no wbinvd on the VM entry path. I don't think
>>> anything is being said explicitly anywhere on whether cache
>>> contents are being taken into consideration when CD=0 but PAT
>>> enforces UC. 
>>> 
>> 
>> I think we don't need worry about hypervisor touch guest memory when
>> guest UC. I draft 2 tests, monitoring various events during guest UC
>> period. 
>> 
>> Test 1 add wbinvd before vmentry. When guest booting, it hungs 10s ~
>> 60s at vcpu0 UC stage, with bunches of vmexit caused by lapic timer
>> interrupt storm. Test 2 is our current patch. It shows during guest
>> UC, vmexit only triggerred by interrupt/ CR access/ MSR access/
>> wbinvd. With these vmexits hypervisor will not touch any guest
>> memory. 
>> 
>> For test1 lapic timer interrupt storm triggered by the 'wbinvd'
>> (without it everything works fine. I didn't dig out the reason --
>> maybe wbinvd involved into tricky vmentry microcode process?), but
>> anyway, test 2 demonstrates that hypervisor will not touch guest
>> memory during guest UC period. 
> 
> That storm is a problem, indeed, but what you did isn't meaningful
> in any way: You just sampled a specific (presumably Linux) guest
> case, but code like this needs to cover the general case (i.e. without
> us knowing whether or when the guest might - temporarily or
> permanently - suppress caching).
> 
> So saying that in this specific case guest memory isn't being touched
> doesn't allow us to draw any conclusions other than that perhaps we
> need to monitor whether guest memory is being accessed (by setting
> a flag in the HVM copy/clear routines), and gate the invocation of
> wbinvd based on that. It's clear though that this would still not
> cover speculative reads.
> 
> Jan

OK, I will send out a protection patch, adding flag indicating guest memory 
access to prevent interrupt storm, though it seems not elegant enough. Whenever 
the interrupt storm got root caused and fixed, the protection flag can be 
removed.

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