From 63952b1e3eb8cf1653fb8f8b62eabbc62e871572 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Mon, 15 Apr 2019 20:26:17 +0200 Subject: [PATCH] 4.19-stable patches added patches: acpica-aml-interpreter-add-region-addresses-in-global-list-during-initialization.patch arm64-dts-rockchip-fix-vcc_host1_5v-gpio-polarity-on-rk3328-rock64.patch arm64-dts-rockchip-fix-vcc_host1_5v-pin-assign-on-rk3328-rock64.patch kvm-x86-nvmx-close-leak-of-l0-s-x2apic-msrs-cve-2019-3887.patch kvm-x86-nvmx-fix-x2apic-vtpr-read-intercept.patch --- ...in-global-list-during-initialization.patch | 45 ++++++ ...t1_5v-gpio-polarity-on-rk3328-rock64.patch | 35 +++++ ...host1_5v-pin-assign-on-rk3328-rock64.patch | 43 ++++++ ...ak-of-l0-s-x2apic-msrs-cve-2019-3887.patch | 134 ++++++++++++++++++ ...-nvmx-fix-x2apic-vtpr-read-intercept.patch | 47 ++++++ queue-4.19/series | 5 + 6 files changed, 309 insertions(+) create mode 100644 queue-4.19/acpica-aml-interpreter-add-region-addresses-in-global-list-during-initialization.patch create mode 100644 queue-4.19/arm64-dts-rockchip-fix-vcc_host1_5v-gpio-polarity-on-rk3328-rock64.patch create mode 100644 queue-4.19/arm64-dts-rockchip-fix-vcc_host1_5v-pin-assign-on-rk3328-rock64.patch create mode 100644 queue-4.19/kvm-x86-nvmx-close-leak-of-l0-s-x2apic-msrs-cve-2019-3887.patch create mode 100644 queue-4.19/kvm-x86-nvmx-fix-x2apic-vtpr-read-intercept.patch diff --git a/queue-4.19/acpica-aml-interpreter-add-region-addresses-in-global-list-during-initialization.patch b/queue-4.19/acpica-aml-interpreter-add-region-addresses-in-global-list-during-initialization.patch new file mode 100644 index 0000000000..7f461dd4d8 --- /dev/null +++ b/queue-4.19/acpica-aml-interpreter-add-region-addresses-in-global-list-during-initialization.patch @@ -0,0 +1,45 @@ +From 4abb951b73ff0a8a979113ef185651aa3c8da19b Mon Sep 17 00:00:00 2001 +From: Erik Schmauss +Date: Wed, 17 Oct 2018 14:09:35 -0700 +Subject: ACPICA: AML interpreter: add region addresses in global list during initialization + +From: Erik Schmauss + +commit 4abb951b73ff0a8a979113ef185651aa3c8da19b upstream. + +The table load process omitted adding the operation region address +range to the global list. This omission is problematic because the OS +queries the global list to check for address range conflicts before +deciding which drivers to load. This commit may result in warning +messages that look like the following: + +[ 7.871761] ACPI Warning: system_IO range 0x00000428-0x0000042F conflicts with op_region 0x00000400-0x0000047F (\PMIO) (20180531/utaddress-213) +[ 7.871769] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver + +However, these messages do not signify regressions. It is a result of +properly adding address ranges within the global address list. + +Link: https://bugzilla.kernel.org/show_bug.cgi?id=200011 +Tested-by: Jean-Marc Lenoir +Signed-off-by: Erik Schmauss +Cc: All applicable +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/acpi/acpica/dsopcode.c | 4 ++++ + 1 file changed, 4 insertions(+) + +--- a/drivers/acpi/acpica/dsopcode.c ++++ b/drivers/acpi/acpica/dsopcode.c +@@ -523,6 +523,10 @@ acpi_ds_eval_table_region_operands(struc + ACPI_FORMAT_UINT64(obj_desc->region.address), + obj_desc->region.length)); + ++ status = acpi_ut_add_address_range(obj_desc->region.space_id, ++ obj_desc->region.address, ++ obj_desc->region.length, node); ++ + /* Now the address and length are valid for this opregion */ + + obj_desc->region.flags |= AOPOBJ_DATA_VALID; diff --git a/queue-4.19/arm64-dts-rockchip-fix-vcc_host1_5v-gpio-polarity-on-rk3328-rock64.patch b/queue-4.19/arm64-dts-rockchip-fix-vcc_host1_5v-gpio-polarity-on-rk3328-rock64.patch new file mode 100644 index 0000000000..1a0a67836a --- /dev/null +++ b/queue-4.19/arm64-dts-rockchip-fix-vcc_host1_5v-gpio-polarity-on-rk3328-rock64.patch @@ -0,0 +1,35 @@ +From a8772e5d826d0f61f8aa9c284b3ab49035d5273d Mon Sep 17 00:00:00 2001 +From: Tomohiro Mayama +Date: Sun, 10 Mar 2019 01:10:12 +0900 +Subject: arm64: dts: rockchip: Fix vcc_host1_5v GPIO polarity on rk3328-rock64 + +From: Tomohiro Mayama + +commit a8772e5d826d0f61f8aa9c284b3ab49035d5273d upstream. + +This patch makes USB ports functioning again. + +Fixes: 955bebde057e ("arm64: dts: rockchip: add rk3328-rock64 board") +Cc: stable@vger.kernel.org +Suggested-by: Robin Murphy +Signed-off-by: Tomohiro Mayama +Tested-by: Katsuhiro Suzuki +Signed-off-by: Heiko Stuebner +Signed-off-by: Greg Kroah-Hartman + +--- + arch/arm64/boot/dts/rockchip/rk3328-rock64.dts | 3 +-- + 1 file changed, 1 insertion(+), 2 deletions(-) + +--- a/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts ++++ b/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts +@@ -45,8 +45,7 @@ + + vcc_host1_5v: vcc_otg_5v: vcc-host1-5v-regulator { + compatible = "regulator-fixed"; +- enable-active-high; +- gpio = <&gpio0 RK_PA2 GPIO_ACTIVE_HIGH>; ++ gpio = <&gpio0 RK_PA2 GPIO_ACTIVE_LOW>; + pinctrl-names = "default"; + pinctrl-0 = <&usb20_host_drv>; + regulator-name = "vcc_host1_5v"; diff --git a/queue-4.19/arm64-dts-rockchip-fix-vcc_host1_5v-pin-assign-on-rk3328-rock64.patch b/queue-4.19/arm64-dts-rockchip-fix-vcc_host1_5v-pin-assign-on-rk3328-rock64.patch new file mode 100644 index 0000000000..1dc34444f9 --- /dev/null +++ b/queue-4.19/arm64-dts-rockchip-fix-vcc_host1_5v-pin-assign-on-rk3328-rock64.patch @@ -0,0 +1,43 @@ +From ef05bcb60c1a8841e38c91923ba998181117a87c Mon Sep 17 00:00:00 2001 +From: Katsuhiro Suzuki +Date: Fri, 7 Sep 2018 00:39:47 +0900 +Subject: arm64: dts: rockchip: fix vcc_host1_5v pin assign on rk3328-rock64 + +From: Katsuhiro Suzuki + +commit ef05bcb60c1a8841e38c91923ba998181117a87c upstream. + +This patch fixes pin assign of vcc_host1_5v. This regulator is +controlled by USB20_HOST_DRV signal. + +ROCK64 schematic says that GPIO0_A2 pin is used as USB20_HOST_DRV. +GPIO0_D3 pin is for SPDIF_TX_M0. + +Signed-off-by: Katsuhiro Suzuki +Signed-off-by: Heiko Stuebner +Signed-off-by: Greg Kroah-Hartman + +--- + arch/arm64/boot/dts/rockchip/rk3328-rock64.dts | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts ++++ b/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts +@@ -46,7 +46,7 @@ + vcc_host1_5v: vcc_otg_5v: vcc-host1-5v-regulator { + compatible = "regulator-fixed"; + enable-active-high; +- gpio = <&gpio0 RK_PD3 GPIO_ACTIVE_HIGH>; ++ gpio = <&gpio0 RK_PA2 GPIO_ACTIVE_HIGH>; + pinctrl-names = "default"; + pinctrl-0 = <&usb20_host_drv>; + regulator-name = "vcc_host1_5v"; +@@ -238,7 +238,7 @@ + + usb2 { + usb20_host_drv: usb20-host-drv { +- rockchip,pins = <0 RK_PD3 RK_FUNC_GPIO &pcfg_pull_none>; ++ rockchip,pins = <0 RK_PA2 RK_FUNC_GPIO &pcfg_pull_none>; + }; + }; + diff --git a/queue-4.19/kvm-x86-nvmx-close-leak-of-l0-s-x2apic-msrs-cve-2019-3887.patch b/queue-4.19/kvm-x86-nvmx-close-leak-of-l0-s-x2apic-msrs-cve-2019-3887.patch new file mode 100644 index 0000000000..9df3f41bc9 --- /dev/null +++ b/queue-4.19/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.c | 72 ++++++++++++++++++++++++++++++++--------------------- + 1 file changed, 44 insertions(+), 28 deletions(-) + +--- a/arch/x86/kvm/vmx.c ++++ b/arch/x86/kvm/vmx.c +@@ -11582,6 +11582,17 @@ static int nested_vmx_check_tpr_shadow_c + return 0; + } + ++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. +@@ -11623,39 +11634,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-4.19/kvm-x86-nvmx-fix-x2apic-vtpr-read-intercept.patch b/queue-4.19/kvm-x86-nvmx-fix-x2apic-vtpr-read-intercept.patch new file mode 100644 index 0000000000..50b2f18291 --- /dev/null +++ b/queue-4.19/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.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/x86/kvm/vmx.c ++++ b/arch/x86/kvm/vmx.c +@@ -11660,7 +11660,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-4.19/series b/queue-4.19/series index 06c6b885fc..1fdde7a11b 100644 --- a/queue-4.19/series +++ b/queue-4.19/series @@ -94,3 +94,8 @@ dm-integrity-change-memcmp-to-strncmp-in-dm_integrity_ctr.patch dm-revert-8f50e358153d-dm-limit-the-max-bio-size-as-bio_max_pages-page_size.patch dm-table-propagate-bdi_cap_stable_writes-to-fix-sporadic-checksum-errors.patch dm-integrity-fix-deadlock-with-overlapping-i-o.patch +arm64-dts-rockchip-fix-vcc_host1_5v-pin-assign-on-rk3328-rock64.patch +arm64-dts-rockchip-fix-vcc_host1_5v-gpio-polarity-on-rk3328-rock64.patch +acpica-aml-interpreter-add-region-addresses-in-global-list-during-initialization.patch +kvm-x86-nvmx-close-leak-of-l0-s-x2apic-msrs-cve-2019-3887.patch +kvm-x86-nvmx-fix-x2apic-vtpr-read-intercept.patch -- 2.39.2