linux-kernel - [PATCH 5/5] KVM: x86: add capability to get/set CPL

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1399992941-11600-6-git-send-email-pbonzini@redhat.com>
Date:	Tue, 13 May 2014 16:55:41 +0200
From:	Paolo Bonzini <pbonzini@...hat.com>
To:	linux-kernel@...r.kernel.org
Cc:	jan.kiszka@...mens.com, kvm@...r.kernel.org, gleb@...nel.org,
	avi.kivity@...il.com
Subject: [PATCH 5/5] KVM: x86: add capability to get/set CPL

Until now, KVM used to assume that CS.RPL could always be used as the CPL
value when KVM_SET_SREGS is called.  Unfortunately this is not the case.
If userspace decides to call KVM_GET_SREGS/KVM_SET_SREGS exactly after
CR0.PE has been set to 1, but before the long jump that reloads CS, the
CPL will be reset to bits 0-1 of CS (aka CS.RPL).  This can work or not,
depending on the placement of the code that transitions to protected
mode.  If CS.RPL != 0 the emulator will see CS.RPL != CS.DPL (the DPL
will always be zero) and fail to fetch the next instruction of the
transition code.

To trigger this using QEMU, it is enough to send "info cpus" continuously
while running iPXE (which places its code for real->protected mode in
the EBDA).  iPXE does a lot of transitions, and the guest will crash
very quickly.

Signed-off-by: Paolo Bonzini <pbonzini@...hat.com>
---
 arch/x86/include/asm/kvm_host.h | 2 ++
 arch/x86/kvm/x86.c              | 7 ++++++-
 include/uapi/linux/kvm.h        | 1 +
 3 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 0bc2d91c8a97..5a85423f4e65 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -574,6 +574,8 @@ struct kvm_arch {
 	struct mutex apic_map_lock;
 	struct kvm_apic_map *apic_map;
 
+	bool set_cpl;
+
 	unsigned int tss_addr;
 	struct page *apic_access_page;
 
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index ca0a1d38fa51..94c6c77e7a9f 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -2656,6 +2656,7 @@ int kvm_dev_ioctl_check_extension(long ext)
 	case KVM_CAP_HYPERV_TIME:
 	case KVM_CAP_IOAPIC_POLARITY_IGNORED:
 	case KVM_CAP_ENABLE_CAP_VM:
+	case KVM_CAP_X86_CPL:
 #ifdef CONFIG_KVM_DEVICE_ASSIGNMENT
 	case KVM_CAP_ASSIGN_DEV_IRQ:
 	case KVM_CAP_PCI_2_3:
@@ -3682,6 +3683,10 @@ static int kvm_vm_ioctl_enable_cap(struct kvm *kvm, struct kvm_enable_cap *cap)
 		return -EINVAL;
 
 	switch (cap->cap) {
+	case KVM_CAP_X86_CPL:
+		kvm->arch.set_cpl = 1;
+		r = 0;
+		break;
 	default:
 		r = -EINVAL;
 		break;
@@ -6678,7 +6683,7 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu,
 		pr_debug("Set back pending irq %d\n", pending_vec);
 	}
 
-	kvm_set_segment(vcpu, &sregs->cs, VCPU_SREG_CS, false);
+	kvm_set_segment(vcpu, &sregs->cs, VCPU_SREG_CS, vcpu->kvm->arch.set_cpl);
 	kvm_set_segment(vcpu, &sregs->ds, VCPU_SREG_DS, false);
 	kvm_set_segment(vcpu, &sregs->es, VCPU_SREG_ES, false);
 	kvm_set_segment(vcpu, &sregs->fs, VCPU_SREG_FS, false);
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 2b83cf35437a..4bcf34aa1b3b 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -748,6 +748,7 @@ struct kvm_ppc_smmu_info {
 #define KVM_CAP_S390_IRQCHIP 99
 #define KVM_CAP_IOEVENTFD_NO_LENGTH 100
 #define KVM_CAP_VM_ATTRIBUTES 101
+#define KVM_CAP_X86_CPL 102
 
 #ifdef KVM_CAP_IRQ_ROUTING
 
-- 
1.8.3.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/