On 5/9/20 7:59 AM, Paolo Bonzini wrote: > On 09/05/20 00:09, Jim Mattson wrote: >>> + if (static_cpu_has(X86_FEATURE_PKU) && >>> + kvm_read_cr4_bits(vcpu, X86_CR4_PKE) && >>> + vcpu->arch.pkru != vcpu->arch.host_pkru) >>> + __write_pkru(vcpu->arch.pkru); >> This doesn't seem quite right to me. Though rdpkru and wrpkru are >> contingent upon CR4.PKE, the PKRU resource isn't. It can be read with >> XSAVE and written with XRSTOR. So, if we don't set the guest PKRU >> value here, the guest can read the host value, which seems dodgy at >> best. >> >> Perhaps the second conjunct should be: (kvm_read_cr4_bits(vcpu, >> X86_CR4_PKE) || (vcpu->arch.xcr0 & XFEATURE_MASK_PKRU)). Thanks Jim. > > You're right. The bug was preexistent, but we should fix it in 5.7 and > stable as well. Paolo, Do you want me to send this fix separately? Or I will send v3 just adding this fix. Thanks > >>> } >>> EXPORT_SYMBOL_GPL(kvm_load_guest_xsave_state); >>> >>> void kvm_load_host_xsave_state(struct kvm_vcpu *vcpu) >>> { >>> + /* >>> + * eager fpu is enabled if PKEY is supported and CR4 is switched >>> + * back on host, so it is safe to read guest PKRU from current >>> + * XSAVE. >>> + */ >> I don't understand the relevance of this comment to the code below. >> > > It's probably stale. Will remove it. > > Paolo >