From: Greg Kroah-Hartman Date: Mon, 15 Apr 2019 18:33:02 +0000 (+0200) Subject: 5.0-stable patches X-Git-Tag: v4.9.169~4 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=3ca989fdb5cc057b16fd9fde388cd03666176c26;p=thirdparty%2Fkernel%2Fstable-queue.git 5.0-stable patches added patches: drm-virtio-do-not-reuse-resource-ids.patch kvm-x86-nvmx-close-leak-of-l0-s-x2apic-msrs-cve-2019-3887.patch kvm-x86-nvmx-fix-x2apic-vtpr-read-intercept.patch --- diff --git a/queue-5.0/drm-virtio-do-not-reuse-resource-ids.patch b/queue-5.0/drm-virtio-do-not-reuse-resource-ids.patch new file mode 100644 index 00000000000..f6cb45ba477 --- /dev/null +++ b/queue-5.0/drm-virtio-do-not-reuse-resource-ids.patch @@ -0,0 +1,64 @@ +From 16065fcdd19ddb9e093192914ac863884f308766 Mon Sep 17 00:00:00 2001 +From: Gerd Hoffmann +Date: Fri, 8 Feb 2019 15:04:09 +0100 +Subject: drm/virtio: do NOT reuse resource ids + +From: Gerd Hoffmann + +commit 16065fcdd19ddb9e093192914ac863884f308766 upstream. + +Bisected guest kernel changes crashing qemu. Landed at +"6c1cd97bda drm/virtio: fix resource id handling". Looked again, and +noticed we where not only leaking *some* ids, but *all* ids. The old +code never ever called virtio_gpu_resource_id_put(). + +So, commit 6c1cd97bda effectively makes the linux kernel starting +re-using IDs after releasing them, and apparently virglrenderer can't +deal with that. Oops. + +This patch puts a temporary stopgap into place for the 5.0 release. + +Signed-off-by: Gerd Hoffmann +Reviewed-by: Dave Airlie +Signed-off-by: Dave Airlie +Link: https://patchwork.freedesktop.org/patch/msgid/20190208140409.15280-1-kraxel@redhat.com +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/virtio/virtgpu_object.c | 13 +++++++++++++ + 1 file changed, 13 insertions(+) + +--- a/drivers/gpu/drm/virtio/virtgpu_object.c ++++ b/drivers/gpu/drm/virtio/virtgpu_object.c +@@ -28,10 +28,21 @@ + static int virtio_gpu_resource_id_get(struct virtio_gpu_device *vgdev, + uint32_t *resid) + { ++#if 0 + int handle = ida_alloc(&vgdev->resource_ida, GFP_KERNEL); + + if (handle < 0) + return handle; ++#else ++ static int handle; ++ ++ /* ++ * FIXME: dirty hack to avoid re-using IDs, virglrenderer ++ * can't deal with that. Needs fixing in virglrenderer, also ++ * should figure a better way to handle that in the guest. ++ */ ++ handle++; ++#endif + + *resid = handle + 1; + return 0; +@@ -39,7 +50,9 @@ static int virtio_gpu_resource_id_get(st + + static void virtio_gpu_resource_id_put(struct virtio_gpu_device *vgdev, uint32_t id) + { ++#if 0 + ida_free(&vgdev->resource_ida, id - 1); ++#endif + } + + static void virtio_gpu_ttm_bo_destroy(struct ttm_buffer_object *tbo) diff --git a/queue-5.0/kvm-x86-nvmx-close-leak-of-l0-s-x2apic-msrs-cve-2019-3887.patch b/queue-5.0/kvm-x86-nvmx-close-leak-of-l0-s-x2apic-msrs-cve-2019-3887.patch new file mode 100644 index 00000000000..27922b4cb67 --- /dev/null +++ b/queue-5.0/kvm-x86-nvmx-close-leak-of-l0-s-x2apic-msrs-cve-2019-3887.patch @@ -0,0 +1,134 @@ +From acff78477b9b4f26ecdf65733a4ed77fe837e9dc Mon Sep 17 00:00:00 2001 +From: Marc Orr +Date: Mon, 1 Apr 2019 23:55:59 -0700 +Subject: KVM: x86: nVMX: close leak of L0's x2APIC MSRs (CVE-2019-3887) + +From: Marc Orr + +commit acff78477b9b4f26ecdf65733a4ed77fe837e9dc upstream. + +The nested_vmx_prepare_msr_bitmap() function doesn't directly guard the +x2APIC MSR intercepts with the "virtualize x2APIC mode" MSR. As a +result, we discovered the potential for a buggy or malicious L1 to get +access to L0's x2APIC MSRs, via an L2, as follows. + +1. L1 executes WRMSR(IA32_SPEC_CTRL, 1). This causes the spec_ctrl +variable, in nested_vmx_prepare_msr_bitmap() to become true. +2. L1 disables "virtualize x2APIC mode" in VMCS12. +3. L1 enables "APIC-register virtualization" in VMCS12. + +Now, KVM will set VMCS02's x2APIC MSR intercepts from VMCS12, and then +set "virtualize x2APIC mode" to 0 in VMCS02. Oops. + +This patch closes the leak by explicitly guarding VMCS02's x2APIC MSR +intercepts with VMCS12's "virtualize x2APIC mode" control. + +The scenario outlined above and fix prescribed here, were verified with +a related patch in kvm-unit-tests titled "Add leak scenario to +virt_x2apic_mode_test". + +Note, it looks like this issue may have been introduced inadvertently +during a merge---see 15303ba5d1cd. + +Signed-off-by: Marc Orr +Reviewed-by: Jim Mattson +Signed-off-by: Paolo Bonzini +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kvm/vmx/nested.c | 72 ++++++++++++++++++++++++++++------------------ + 1 file changed, 44 insertions(+), 28 deletions(-) + +--- a/arch/x86/kvm/vmx/nested.c ++++ b/arch/x86/kvm/vmx/nested.c +@@ -500,6 +500,17 @@ static void nested_vmx_disable_intercept + } + } + ++static inline void enable_x2apic_msr_intercepts(unsigned long *msr_bitmap) { ++ int msr; ++ ++ for (msr = 0x800; msr <= 0x8ff; msr += BITS_PER_LONG) { ++ unsigned word = msr / BITS_PER_LONG; ++ ++ msr_bitmap[word] = ~0; ++ msr_bitmap[word + (0x800 / sizeof(long))] = ~0; ++ } ++} ++ + /* + * Merge L0's and L1's MSR bitmap, return false to indicate that + * we do not use the hardware. +@@ -541,39 +552,44 @@ static inline bool nested_vmx_prepare_ms + return false; + + msr_bitmap_l1 = (unsigned long *)kmap(page); +- if (nested_cpu_has_apic_reg_virt(vmcs12)) { +- /* +- * L0 need not intercept reads for MSRs between 0x800 and 0x8ff, it +- * just lets the processor take the value from the virtual-APIC page; +- * take those 256 bits directly from the L1 bitmap. +- */ +- for (msr = 0x800; msr <= 0x8ff; msr += BITS_PER_LONG) { +- unsigned word = msr / BITS_PER_LONG; +- msr_bitmap_l0[word] = msr_bitmap_l1[word]; +- msr_bitmap_l0[word + (0x800 / sizeof(long))] = ~0; +- } +- } else { +- for (msr = 0x800; msr <= 0x8ff; msr += BITS_PER_LONG) { +- unsigned word = msr / BITS_PER_LONG; +- msr_bitmap_l0[word] = ~0; +- msr_bitmap_l0[word + (0x800 / sizeof(long))] = ~0; +- } +- } + +- nested_vmx_disable_intercept_for_msr( +- msr_bitmap_l1, msr_bitmap_l0, +- X2APIC_MSR(APIC_TASKPRI), +- MSR_TYPE_W); ++ /* ++ * To keep the control flow simple, pay eight 8-byte writes (sixteen ++ * 4-byte writes on 32-bit systems) up front to enable intercepts for ++ * the x2APIC MSR range and selectively disable them below. ++ */ ++ enable_x2apic_msr_intercepts(msr_bitmap_l0); ++ ++ if (nested_cpu_has_virt_x2apic_mode(vmcs12)) { ++ if (nested_cpu_has_apic_reg_virt(vmcs12)) { ++ /* ++ * L0 need not intercept reads for MSRs between 0x800 ++ * and 0x8ff, it just lets the processor take the value ++ * from the virtual-APIC page; take those 256 bits ++ * directly from the L1 bitmap. ++ */ ++ for (msr = 0x800; msr <= 0x8ff; msr += BITS_PER_LONG) { ++ unsigned word = msr / BITS_PER_LONG; ++ ++ msr_bitmap_l0[word] = msr_bitmap_l1[word]; ++ } ++ } + +- if (nested_cpu_has_vid(vmcs12)) { +- nested_vmx_disable_intercept_for_msr( +- msr_bitmap_l1, msr_bitmap_l0, +- X2APIC_MSR(APIC_EOI), +- MSR_TYPE_W); + nested_vmx_disable_intercept_for_msr( + msr_bitmap_l1, msr_bitmap_l0, +- X2APIC_MSR(APIC_SELF_IPI), ++ X2APIC_MSR(APIC_TASKPRI), + MSR_TYPE_W); ++ ++ if (nested_cpu_has_vid(vmcs12)) { ++ nested_vmx_disable_intercept_for_msr( ++ msr_bitmap_l1, msr_bitmap_l0, ++ X2APIC_MSR(APIC_EOI), ++ MSR_TYPE_W); ++ nested_vmx_disable_intercept_for_msr( ++ msr_bitmap_l1, msr_bitmap_l0, ++ X2APIC_MSR(APIC_SELF_IPI), ++ MSR_TYPE_W); ++ } + } + + if (spec_ctrl) diff --git a/queue-5.0/kvm-x86-nvmx-fix-x2apic-vtpr-read-intercept.patch b/queue-5.0/kvm-x86-nvmx-fix-x2apic-vtpr-read-intercept.patch new file mode 100644 index 00000000000..90d18c6358c --- /dev/null +++ b/queue-5.0/kvm-x86-nvmx-fix-x2apic-vtpr-read-intercept.patch @@ -0,0 +1,47 @@ +From c73f4c998e1fd4249b9edfa39e23f4fda2b9b041 Mon Sep 17 00:00:00 2001 +From: Marc Orr +Date: Mon, 1 Apr 2019 23:56:00 -0700 +Subject: KVM: x86: nVMX: fix x2APIC VTPR read intercept + +From: Marc Orr + +commit c73f4c998e1fd4249b9edfa39e23f4fda2b9b041 upstream. + +Referring to the "VIRTUALIZING MSR-BASED APIC ACCESSES" chapter of the +SDM, when "virtualize x2APIC mode" is 1 and "APIC-register +virtualization" is 0, a RDMSR of 808H should return the VTPR from the +virtual APIC page. + +However, for nested, KVM currently fails to disable the read intercept +for this MSR. This means that a RDMSR exit takes precedence over +"virtualize x2APIC mode", and KVM passes through L1's TPR to L2, +instead of sourcing the value from L2's virtual APIC page. + +This patch fixes the issue by disabling the read intercept, in VMCS02, +for the VTPR when "APIC-register virtualization" is 0. + +The issue described above and fix prescribed here, were verified with +a related patch in kvm-unit-tests titled "Test VMX's virtualize x2APIC +mode w/ nested". + +Signed-off-by: Marc Orr +Reviewed-by: Jim Mattson +Fixes: c992384bde84f ("KVM: vmx: speed up MSR bitmap merge") +Signed-off-by: Paolo Bonzini +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kvm/vmx/nested.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/x86/kvm/vmx/nested.c ++++ b/arch/x86/kvm/vmx/nested.c +@@ -578,7 +578,7 @@ static inline bool nested_vmx_prepare_ms + nested_vmx_disable_intercept_for_msr( + msr_bitmap_l1, msr_bitmap_l0, + X2APIC_MSR(APIC_TASKPRI), +- MSR_TYPE_W); ++ MSR_TYPE_R | MSR_TYPE_W); + + if (nested_cpu_has_vid(vmcs12)) { + nested_vmx_disable_intercept_for_msr( diff --git a/queue-5.0/series b/queue-5.0/series index c47acedfb61..b22a3fae063 100644 --- a/queue-5.0/series +++ b/queue-5.0/series @@ -112,3 +112,6 @@ dm-revert-8f50e358153d-dm-limit-the-max-bio-size-as-bio_max_pages-page_size.patc dm-table-propagate-bdi_cap_stable_writes-to-fix-sporadic-checksum-errors.patch dm-disable-discard-if-the-underlying-storage-no-longer-supports-it.patch dm-integrity-fix-deadlock-with-overlapping-i-o.patch +kvm-x86-nvmx-close-leak-of-l0-s-x2apic-msrs-cve-2019-3887.patch +kvm-x86-nvmx-fix-x2apic-vtpr-read-intercept.patch +drm-virtio-do-not-reuse-resource-ids.patch