From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: [PATCH 3/3 V3] XSA-60 security hole: cr0.cd handling Date: Wed, 30 Oct 2013 08:05:52 +0000 Message-ID: <5270CBF002000078000FDED1@nat28.tlf.novell.com> References: <5266AE0D02000078000FCB84@nat28.tlf.novell.com> <5268098102000078000A570B@nat28.tlf.novell.com> <526E208302000078000FD1F6@nat28.tlf.novell.com> <526E3C7A02000078000FD285@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jinsong Liu , Jun Nakajima Cc: "tim@xen.org" , "keir@xen.org" , "andrew.cooper3@citrix.com" , Eddie Dong , "zhenzhong.duan@oracle.com" , "xen-devel@lists.xen.org" , Will Auld , "suravee.suthikulpanit@amd.com" , "sherry.hurwitz@amd.com" List-Id: xen-devel@lists.xenproject.org >>> On 29.10.13 at 17:52, "Liu, Jinsong" 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