--- /dev/null
+From 4abb951b73ff0a8a979113ef185651aa3c8da19b Mon Sep 17 00:00:00 2001
+From: Erik Schmauss <erik.schmauss@intel.com>
+Date: Wed, 17 Oct 2018 14:09:35 -0700
+Subject: ACPICA: AML interpreter: add region addresses in global list during initialization
+
+From: Erik Schmauss <erik.schmauss@intel.com>
+
+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 <archlinux@jihemel.com>
+Signed-off-by: Erik Schmauss <erik.schmauss@intel.com>
+Cc: All applicable <stable@vger.kernel.org>
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
--- /dev/null
+From a8772e5d826d0f61f8aa9c284b3ab49035d5273d Mon Sep 17 00:00:00 2001
+From: Tomohiro Mayama <parly-gh@iris.mystia.org>
+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 <parly-gh@iris.mystia.org>
+
+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 <robin.murphy@arm.com>
+Signed-off-by: Tomohiro Mayama <parly-gh@iris.mystia.org>
+Tested-by: Katsuhiro Suzuki <katsuhiro@katsuster.net>
+Signed-off-by: Heiko Stuebner <heiko@sntech.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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";
--- /dev/null
+From ef05bcb60c1a8841e38c91923ba998181117a87c Mon Sep 17 00:00:00 2001
+From: Katsuhiro Suzuki <katsuhiro@katsuster.net>
+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 <katsuhiro@katsuster.net>
+
+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 <katsuhiro@katsuster.net>
+Signed-off-by: Heiko Stuebner <heiko@sntech.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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>;
+ };
+ };
+
--- /dev/null
+From acff78477b9b4f26ecdf65733a4ed77fe837e9dc Mon Sep 17 00:00:00 2001
+From: Marc Orr <marcorr@google.com>
+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 <marcorr@google.com>
+
+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 <marcorr@google.com>
+Reviewed-by: Jim Mattson <jmattson@google.com>
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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)
--- /dev/null
+From c73f4c998e1fd4249b9edfa39e23f4fda2b9b041 Mon Sep 17 00:00:00 2001
+From: Marc Orr <marcorr@google.com>
+Date: Mon, 1 Apr 2019 23:56:00 -0700
+Subject: KVM: x86: nVMX: fix x2APIC VTPR read intercept
+
+From: Marc Orr <marcorr@google.com>
+
+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 <marcorr@google.com>
+Reviewed-by: Jim Mattson <jmattson@google.com>
+Fixes: c992384bde84f ("KVM: vmx: speed up MSR bitmap merge")
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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(
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
projects / thirdparty / kernel / stable-queue.git / commitdiff
