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

["Jan Beulich" <JBeulich@xxxxxxxx>]

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


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