[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 3/3] XSA-60 security hole: cr0.cd handling
>>> On 16.10.13 at 20:38, "Liu, Jinsong" <jinsong.liu@xxxxxxxxx> wrote: > +void hvm_shadow_handle_cd(struct vcpu *v, unsigned long value) > +{ > + if ( value & X86_CR0_CD ) > + { > + /* Entering no fill cache mode. */ > + spin_lock(&v->domain->arch.hvm_domain.uc_lock); > + v->arch.hvm_vcpu.cache_mode = NO_FILL_CACHE_MODE; > + > + if ( !v->domain->arch.hvm_domain.is_in_uc_mode ) > + { > + /* Flush physical caches. */ > + on_each_cpu(local_flush_cache, NULL, 1); > + hvm_set_uc_mode(v, 1); No matter how you order these two, there's a window during which new cache contents could accumulate. I think you need to pause all but the current vCPU around this pair of operations. > @@ -921,8 +921,6 @@ static int construct_vmcs(struct vcpu *v) > vmx_disable_intercept_for_msr(v, MSR_IA32_SYSENTER_CS, MSR_TYPE_R | > MSR_TYPE_W); > vmx_disable_intercept_for_msr(v, MSR_IA32_SYSENTER_ESP, MSR_TYPE_R | > MSR_TYPE_W); > vmx_disable_intercept_for_msr(v, MSR_IA32_SYSENTER_EIP, MSR_TYPE_R | > MSR_TYPE_W); > - if ( paging_mode_hap(d) ) > - vmx_disable_intercept_for_msr(v, MSR_IA32_CR_PAT, MSR_TYPE_R | > MSR_TYPE_W); Could you not retain this when !iommu_enabled || iommu_snoop? Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |