diff options
Diffstat (limited to 'common/recipes-kernel/linux/linux-yocto-4.9.21/0004-kvm-nVMX-Disallow-userspace-injected-exceptions-in-g.patch')
-rw-r--r-- | common/recipes-kernel/linux/linux-yocto-4.9.21/0004-kvm-nVMX-Disallow-userspace-injected-exceptions-in-g.patch | 71 |
1 files changed, 71 insertions, 0 deletions
diff --git a/common/recipes-kernel/linux/linux-yocto-4.9.21/0004-kvm-nVMX-Disallow-userspace-injected-exceptions-in-g.patch b/common/recipes-kernel/linux/linux-yocto-4.9.21/0004-kvm-nVMX-Disallow-userspace-injected-exceptions-in-g.patch new file mode 100644 index 00000000..3d7259ab --- /dev/null +++ b/common/recipes-kernel/linux/linux-yocto-4.9.21/0004-kvm-nVMX-Disallow-userspace-injected-exceptions-in-g.patch @@ -0,0 +1,71 @@ +From 230ca3c5a44c752650e6bac9a4fe0eefc5ff0758 Mon Sep 17 00:00:00 2001 +From: Jim Mattson <jmattson@google.com> +Date: Wed, 5 Apr 2017 09:14:40 -0700 +Subject: [PATCH 04/93] kvm: nVMX: Disallow userspace-injected exceptions in + guest mode +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +[ Upstream commit 28d06353881939703c34d82a1465136af176c620 ] + +The userspace exception injection API and code path are entirely +unprepared for exceptions that might cause a VM-exit from L2 to L1, so +the best course of action may be to simply disallow this for now. + +1. The API provides no mechanism for userspace to specify the new DR6 +bits for a #DB exception or the new CR2 value for a #PF +exception. Presumably, userspace is expected to modify these registers +directly with KVM_SET_SREGS before the next KVM_RUN ioctl. However, in +the event that L1 intercepts the exception, these registers should not +be changed. Instead, the new values should be provided in the +exit_qualification field of vmcs12 (Intel SDM vol 3, section 27.1). + +2. In the case of a userspace-injected #DB, inject_pending_event() +clears DR7.GD before calling vmx_queue_exception(). However, in the +event that L1 intercepts the exception, this is too early, because +DR7.GD should not be modified by a #DB that causes a VM-exit directly +(Intel SDM vol 3, section 27.1). + +3. If the injected exception is a #PF, nested_vmx_check_exception() +doesn't properly check whether or not L1 is interested in the +associated error code (using the #PF error code mask and match fields +from vmcs12). It may either return 0 when it should call +nested_vmx_vmexit() or vice versa. + +4. nested_vmx_check_exception() assumes that it is dealing with a +hardware-generated exception intercept from L2, with some of the +relevant details (the VM-exit interruption-information and the exit +qualification) live in vmcs02. For userspace-injected exceptions, this +is not the case. + +5. prepare_vmcs12() assumes that when its exit_intr_info argument +specifies valid information with a valid error code that it can VMREAD +the VM-exit interruption error code from vmcs02. For +userspace-injected exceptions, this is not the case. + +Signed-off-by: Jim Mattson <jmattson@google.com> +Signed-off-by: Radim Krčmář <rkrcmar@redhat.com> +Signed-off-by: Sasha Levin <alexander.levin@microsoft.com> +Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> +--- + arch/x86/kvm/x86.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c +index 9f0f7e2..b27b93d 100644 +--- a/arch/x86/kvm/x86.c ++++ b/arch/x86/kvm/x86.c +@@ -3056,7 +3056,8 @@ static int kvm_vcpu_ioctl_x86_set_vcpu_events(struct kvm_vcpu *vcpu, + return -EINVAL; + + if (events->exception.injected && +- (events->exception.nr > 31 || events->exception.nr == NMI_VECTOR)) ++ (events->exception.nr > 31 || events->exception.nr == NMI_VECTOR || ++ is_guest_mode(vcpu))) + return -EINVAL; + + process_nmi(vcpu); +-- +2.7.4 + |