From patchwork Thu Apr 16 09:10:42 2009 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Marcelo Tosatti X-Patchwork-Id: 18487 Received: from vger.kernel.org (vger.kernel.org [209.132.176.167]) by demeter.kernel.org (8.14.2/8.14.2) with ESMTP id n3G9AwfN004815 for ; Thu, 16 Apr 2009 09:10:59 GMT Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752695AbZDPJK4 (ORCPT ); Thu, 16 Apr 2009 05:10:56 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752522AbZDPJK4 (ORCPT ); Thu, 16 Apr 2009 05:10:56 -0400 Received: from mx2.redhat.com ([66.187.237.31]:48374 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752439AbZDPJKz (ORCPT ); Thu, 16 Apr 2009 05:10:55 -0400 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n3G9AsRf013231 for ; Thu, 16 Apr 2009 05:10:54 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n3G9Ar8G013293; Thu, 16 Apr 2009 05:10:54 -0400 Received: from amt.cnet (vpn-10-194.str.redhat.com [10.32.10.194]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n3G9ApkY028092; Thu, 16 Apr 2009 05:10:52 -0400 Received: from amt.cnet (amt.cnet [127.0.0.1]) by amt.cnet (Postfix) with ESMTP id BE977681246; Thu, 16 Apr 2009 06:10:43 -0300 (BRT) Received: (from marcelo@localhost) by amt.cnet (8.14.3/8.14.3/Submit) id n3G9AgBB009055; Thu, 16 Apr 2009 06:10:42 -0300 Date: Thu, 16 Apr 2009 06:10:42 -0300 From: Marcelo Tosatti To: Avi Kivity Cc: kvm Subject: Re: KVM: x86: use kvm_set_cr3/cr4 in ioctl_set_sregs Message-ID: <20090416091042.GA6709@amt.cnet> References: <20090415221042.GA20127@amt.cnet> <49E6F2AF.9050300@redhat.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <49E6F2AF.9050300@redhat.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-Scanned-By: MIMEDefang 2.58 on 172.16.27.26 Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Thu, Apr 16, 2009 at 11:56:15AM +0300, Avi Kivity wrote: > Marcelo Tosatti wrote: >> Matt T. Yourst notes that kvm_arch_vcpu_ioctl_set_sregs lacks validity >> checking for the new cr3 value: >> >> "Userspace callers of KVM_SET_SREGS can pass a bogus value of cr3 to >> the kernel. This will trigger a NULL pointer access in gfn_to_rmap() >> when userspace next tries to call KVM_RUN on the affected VCPU and kvm >> attempts to activate the new non-existent page table root. >> >> This happens since kvm only validates that cr3 points to a valid guest >> physical memory page when code *inside* the guest sets cr3. However, kvm >> currently trusts the userspace caller (e.g. QEMU) on the host machine to >> always supply a valid page table root, rather than properly validating >> it along with the rest of the reloaded guest state." >> >> http://sourceforge.net/tracker/?func=detail&atid=893831&aid=2687641&group_id=180599 >> >> Follow Avi's suggestion to use kvm_set_cr3, and do the same for >> assigment of cr4. Note kvm_set_cr4 unconditionally resets the mmu >> context, as long as cr4 is valid. >> >> Signed-off-by: Marcelo Tosatti >> >> >> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c >> index 148cde2..89fb3c7 100644 >> --- a/arch/x86/kvm/x86.c >> +++ b/arch/x86/kvm/x86.c >> @@ -3985,25 +3985,19 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu, >> kvm_x86_ops->set_gdt(vcpu, &dt); >> vcpu->arch.cr2 = sregs->cr2; >> - mmu_reset_needed |= vcpu->arch.cr3 != sregs->cr3; >> - vcpu->arch.cr3 = sregs->cr3; >> + kvm_set_cr3(vcpu, sregs->cr3); >> kvm_set_cr8(vcpu, sregs->cr8); >> mmu_reset_needed |= vcpu->arch.shadow_efer != sregs->efer; >> kvm_x86_ops->set_efer(vcpu, sregs->efer); >> kvm_set_apic_base(vcpu, sregs->apic_base); >> - kvm_x86_ops->decache_cr4_guest_bits(vcpu); >> - >> mmu_reset_needed |= vcpu->arch.cr0 != sregs->cr0; >> kvm_x86_ops->set_cr0(vcpu, sregs->cr0); >> vcpu->arch.cr0 = sregs->cr0; >> - mmu_reset_needed |= vcpu->arch.cr4 != sregs->cr4; >> - kvm_x86_ops->set_cr4(vcpu, sregs->cr4); >> - if (!is_long_mode(vcpu) && is_pae(vcpu)) >> - load_pdptrs(vcpu, vcpu->arch.cr3); >> + kvm_set_cr4(vcpu, sregs->cr4); >> if (mmu_reset_needed) >> kvm_mmu_reset_context(vcpu); >> > > Consider the following: > > current state: > cr3 = 0 > cr4.pae = 0 > > new state: > cr3 = 0x800 > cr4.pae = 1 > > When you call kvm_set_cr3(), it will inject a #GP into the guest because > we are setting bit 11 when cr4.pae=0, which is illegal. However the new > cr4.pae=1, so the new state was in fact legal! > > There are a few ways out, one is to first go back to real mode and set > eveything up carefully in the right order (including EFER.LMA and > EFER.LME, and CS.L). The other is to refactor kvm_set_* so that we have > internal setters which won't trigger these faults (but do need to check > at the end that the state is legal). > > This first method is probably better since that's what the guest does > when booting anyway. Humpf. And something like this? Or GP# instead of triple fault? --- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 148cde2..3e63bac 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -3986,7 +3986,10 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu, vcpu->arch.cr2 = sregs->cr2; mmu_reset_needed |= vcpu->arch.cr3 != sregs->cr3; - vcpu->arch.cr3 = sregs->cr3; + if (gfn_to_memslot(vcpu->kvm, sregs->cr3 >> PAGE_SHIFT)) + vcpu->arch.cr3 = sregs->cr3; + else + set_bit(KVM_REQ_TRIPLE_FAULT, &vcpu->requests); kvm_set_cr8(vcpu, sregs->cr8);