From: Greg Kroah-Hartman Date: Mon, 7 Jan 2019 10:39:56 +0000 (+0100) Subject: 4.9-stable patches X-Git-Tag: v4.9.149~16 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=079bcac5c79f792d79c72e455687675ce67dd273;p=thirdparty%2Fkernel%2Fstable-queue.git 4.9-stable patches added patches: arm64-kvm-avoid-setting-the-upper-32-bits-of-vtcr_el2-to-1.patch rtc-m41t80-correct-alarm-month-range-with-rtc-reads.patch tpm-tpm_i2c_nuvoton-use-correct-command-duration-for-tpm-2.x.patch x86-kvm-vmx-do-not-use-vm-exit-instruction-length-for-fast-mmio-when-running-nested.patch --- diff --git a/queue-4.9/arm64-kvm-avoid-setting-the-upper-32-bits-of-vtcr_el2-to-1.patch b/queue-4.9/arm64-kvm-avoid-setting-the-upper-32-bits-of-vtcr_el2-to-1.patch new file mode 100644 index 00000000000..4b6c3423355 --- /dev/null +++ b/queue-4.9/arm64-kvm-avoid-setting-the-upper-32-bits-of-vtcr_el2-to-1.patch @@ -0,0 +1,38 @@ +From df655b75c43fba0f2621680ab261083297fd6d16 Mon Sep 17 00:00:00 2001 +From: Will Deacon +Date: Thu, 13 Dec 2018 16:06:14 +0000 +Subject: arm64: KVM: Avoid setting the upper 32 bits of VTCR_EL2 to 1 + +From: Will Deacon + +commit df655b75c43fba0f2621680ab261083297fd6d16 upstream. + +Although bit 31 of VTCR_EL2 is RES1, we inadvertently end up setting all +of the upper 32 bits to 1 as well because we define VTCR_EL2_RES1 as +signed, which is sign-extended when assigning to kvm->arch.vtcr. + +Lucky for us, the architecture currently treats these upper bits as RES0 +so, whilst we've been naughty, we haven't set fire to anything yet. + +Cc: +Cc: Marc Zyngier +Cc: Christoffer Dall +Signed-off-by: Will Deacon +Signed-off-by: Marc Zyngier +Signed-off-by: Greg Kroah-Hartman + +--- + arch/arm64/include/asm/kvm_arm.h | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/arm64/include/asm/kvm_arm.h ++++ b/arch/arm64/include/asm/kvm_arm.h +@@ -99,7 +99,7 @@ + TCR_EL2_ORGN0_MASK | TCR_EL2_IRGN0_MASK | TCR_EL2_T0SZ_MASK) + + /* VTCR_EL2 Registers bits */ +-#define VTCR_EL2_RES1 (1 << 31) ++#define VTCR_EL2_RES1 (1U << 31) + #define VTCR_EL2_HD (1 << 22) + #define VTCR_EL2_HA (1 << 21) + #define VTCR_EL2_PS_MASK TCR_EL2_PS_MASK diff --git a/queue-4.9/rtc-m41t80-correct-alarm-month-range-with-rtc-reads.patch b/queue-4.9/rtc-m41t80-correct-alarm-month-range-with-rtc-reads.patch new file mode 100644 index 00000000000..d254c8914d4 --- /dev/null +++ b/queue-4.9/rtc-m41t80-correct-alarm-month-range-with-rtc-reads.patch @@ -0,0 +1,41 @@ +From 3cc9ffbb1f51eb4320575a48e4805a8f52e0e26b Mon Sep 17 00:00:00 2001 +From: "Maciej W. Rozycki" +Date: Wed, 7 Nov 2018 02:39:13 +0000 +Subject: rtc: m41t80: Correct alarm month range with RTC reads + +From: Maciej W. Rozycki + +commit 3cc9ffbb1f51eb4320575a48e4805a8f52e0e26b upstream. + +Add the missing adjustment of the month range on alarm reads from the +RTC, correcting an issue coming from commit 9c6dfed92c3e ("rtc: m41t80: +add alarm functionality"). The range is 1-12 for hardware and 0-11 for +`struct rtc_time', and is already correctly handled on alarm writes to +the RTC. + +It was correct up until commit 48e9766726eb ("drivers/rtc/rtc-m41t80.c: +remove disabled alarm functionality") too, which removed the previous +implementation of alarm support. + +Signed-off-by: Maciej W. Rozycki +Fixes: 9c6dfed92c3e ("rtc: m41t80: add alarm functionality") +References: 48e9766726eb ("drivers/rtc/rtc-m41t80.c: remove disabled alarm functionality") +Cc: stable@vger.kernel.org # 4.7+ +Signed-off-by: Alexandre Belloni +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/rtc/rtc-m41t80.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/rtc/rtc-m41t80.c ++++ b/drivers/rtc/rtc-m41t80.c +@@ -333,7 +333,7 @@ static int m41t80_read_alarm(struct devi + alrm->time.tm_min = bcd2bin(alarmvals[3] & 0x7f); + alrm->time.tm_hour = bcd2bin(alarmvals[2] & 0x3f); + alrm->time.tm_mday = bcd2bin(alarmvals[1] & 0x3f); +- alrm->time.tm_mon = bcd2bin(alarmvals[0] & 0x3f); ++ alrm->time.tm_mon = bcd2bin(alarmvals[0] & 0x3f) - 1; + + alrm->enabled = !!(alarmvals[0] & M41T80_ALMON_AFE); + alrm->pending = (flags & M41T80_FLAGS_AF) && alrm->enabled; diff --git a/queue-4.9/series b/queue-4.9/series index 2a4339ed0de..720feb36cb7 100644 --- a/queue-4.9/series +++ b/queue-4.9/series @@ -65,3 +65,7 @@ mips-ensure-pmd_present-returns-false-after-pmd_mknotpresent.patch mips-align-kernel-load-address-to-64kb.patch mips-octeon-mark-rgmii-interface-disabled-on-octeon-iii.patch cifs-fix-error-mapping-for-smb2_lock-command-which-caused-ofd-lock-problem.patch +x86-kvm-vmx-do-not-use-vm-exit-instruction-length-for-fast-mmio-when-running-nested.patch +arm64-kvm-avoid-setting-the-upper-32-bits-of-vtcr_el2-to-1.patch +rtc-m41t80-correct-alarm-month-range-with-rtc-reads.patch +tpm-tpm_i2c_nuvoton-use-correct-command-duration-for-tpm-2.x.patch diff --git a/queue-4.9/tpm-tpm_i2c_nuvoton-use-correct-command-duration-for-tpm-2.x.patch b/queue-4.9/tpm-tpm_i2c_nuvoton-use-correct-command-duration-for-tpm-2.x.patch new file mode 100644 index 00000000000..86882e53faa --- /dev/null +++ b/queue-4.9/tpm-tpm_i2c_nuvoton-use-correct-command-duration-for-tpm-2.x.patch @@ -0,0 +1,54 @@ +From 2ba5780ce30549cf57929b01d8cba6fe656e31c5 Mon Sep 17 00:00:00 2001 +From: Tomas Winkler +Date: Fri, 19 Oct 2018 21:22:47 +0300 +Subject: tpm: tpm_i2c_nuvoton: use correct command duration for TPM 2.x + +From: Tomas Winkler + +commit 2ba5780ce30549cf57929b01d8cba6fe656e31c5 upstream. + +tpm_i2c_nuvoton calculated commands duration using TPM 1.x +values via tpm_calc_ordinal_duration() also for TPM 2.x chips. +Call tpm2_calc_ordinal_duration() for retrieving ordinal +duration for TPM 2.X chips. + +Cc: stable@vger.kernel.org +Cc: Nayna Jain +Signed-off-by: Tomas Winkler +Reviewed-by: Nayna Jain +Tested-by: Nayna Jain (For TPM 2.0) +Reviewed-by: Jarkko Sakkinen +Signed-off-by: Jarkko Sakkinen +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/char/tpm/tpm_i2c_nuvoton.c | 11 +++++++---- + 1 file changed, 7 insertions(+), 4 deletions(-) + +--- a/drivers/char/tpm/tpm_i2c_nuvoton.c ++++ b/drivers/char/tpm/tpm_i2c_nuvoton.c +@@ -369,6 +369,7 @@ static int i2c_nuvoton_send(struct tpm_c + struct device *dev = chip->dev.parent; + struct i2c_client *client = to_i2c_client(dev); + u32 ordinal; ++ unsigned long duration; + size_t count = 0; + int burst_count, bytes2write, retries, rc = -EIO; + +@@ -455,10 +456,12 @@ static int i2c_nuvoton_send(struct tpm_c + return rc; + } + ordinal = be32_to_cpu(*((__be32 *) (buf + 6))); +- rc = i2c_nuvoton_wait_for_data_avail(chip, +- tpm_calc_ordinal_duration(chip, +- ordinal), +- &priv->read_queue); ++ if (chip->flags & TPM_CHIP_FLAG_TPM2) ++ duration = tpm2_calc_ordinal_duration(chip, ordinal); ++ else ++ duration = tpm_calc_ordinal_duration(chip, ordinal); ++ ++ rc = i2c_nuvoton_wait_for_data_avail(chip, duration, &priv->read_queue); + if (rc) { + dev_err(dev, "%s() timeout command duration\n", __func__); + i2c_nuvoton_ready(chip); diff --git a/queue-4.9/x86-kvm-vmx-do-not-use-vm-exit-instruction-length-for-fast-mmio-when-running-nested.patch b/queue-4.9/x86-kvm-vmx-do-not-use-vm-exit-instruction-length-for-fast-mmio-when-running-nested.patch new file mode 100644 index 00000000000..413eb7ce9c5 --- /dev/null +++ b/queue-4.9/x86-kvm-vmx-do-not-use-vm-exit-instruction-length-for-fast-mmio-when-running-nested.patch @@ -0,0 +1,86 @@ +From d391f1207067268261add0485f0f34503539c5b0 Mon Sep 17 00:00:00 2001 +From: Vitaly Kuznetsov +Date: Thu, 25 Jan 2018 16:37:07 +0100 +Subject: x86/kvm/vmx: do not use vm-exit instruction length for fast MMIO when running nested +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Vitaly Kuznetsov + +commit d391f1207067268261add0485f0f34503539c5b0 upstream. + +I was investigating an issue with seabios >= 1.10 which stopped working +for nested KVM on Hyper-V. The problem appears to be in +handle_ept_violation() function: when we do fast mmio we need to skip +the instruction so we do kvm_skip_emulated_instruction(). This, however, +depends on VM_EXIT_INSTRUCTION_LEN field being set correctly in VMCS. +However, this is not the case. + +Intel's manual doesn't mandate VM_EXIT_INSTRUCTION_LEN to be set when +EPT MISCONFIG occurs. While on real hardware it was observed to be set, +some hypervisors follow the spec and don't set it; we end up advancing +IP with some random value. + +I checked with Microsoft and they confirmed they don't fill +VM_EXIT_INSTRUCTION_LEN on EPT MISCONFIG. + +Fix the issue by doing instruction skip through emulator when running +nested. + +Fixes: 68c3b4d1676d870f0453c31d5a52e7e65c7448ae +Suggested-by: Radim Krčmář +Suggested-by: Paolo Bonzini +Signed-off-by: Vitaly Kuznetsov +Acked-by: Michael S. Tsirkin +Signed-off-by: Radim Krčmář +Signed-off-by: Sasha Levin +[mhaboustak: backport to 4.9.y] +Signed-off-by: Mike Haboustak +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kvm/vmx.c | 19 +++++++++++++++++-- + arch/x86/kvm/x86.c | 3 ++- + 2 files changed, 19 insertions(+), 3 deletions(-) + +--- a/arch/x86/kvm/vmx.c ++++ b/arch/x86/kvm/vmx.c +@@ -6548,9 +6548,24 @@ static int handle_ept_misconfig(struct k + + gpa = vmcs_read64(GUEST_PHYSICAL_ADDRESS); + if (!kvm_io_bus_write(vcpu, KVM_FAST_MMIO_BUS, gpa, 0, NULL)) { +- skip_emulated_instruction(vcpu); + trace_kvm_fast_mmio(gpa); +- return 1; ++ /* ++ * Doing kvm_skip_emulated_instruction() depends on undefined ++ * behavior: Intel's manual doesn't mandate ++ * VM_EXIT_INSTRUCTION_LEN to be set in VMCS when EPT MISCONFIG ++ * occurs and while on real hardware it was observed to be set, ++ * other hypervisors (namely Hyper-V) don't set it, we end up ++ * advancing IP with some random value. Disable fast mmio when ++ * running nested and keep it for real hardware in hope that ++ * VM_EXIT_INSTRUCTION_LEN will always be set correctly. ++ */ ++ if (!static_cpu_has(X86_FEATURE_HYPERVISOR)) { ++ skip_emulated_instruction(vcpu); ++ return 1; ++ } ++ else ++ return x86_emulate_instruction(vcpu, gpa, EMULTYPE_SKIP, ++ NULL, 0) == EMULATE_DONE; + } + + ret = handle_mmio_page_fault(vcpu, gpa, true); +--- a/arch/x86/kvm/x86.c ++++ b/arch/x86/kvm/x86.c +@@ -5707,7 +5707,8 @@ int x86_emulate_instruction(struct kvm_v + * handle watchpoints yet, those would be handled in + * the emulate_ops. + */ +- if (kvm_vcpu_check_breakpoint(vcpu, &r)) ++ if (!(emulation_type & EMULTYPE_SKIP) && ++ kvm_vcpu_check_breakpoint(vcpu, &r)) + return r; + + ctxt->interruptibility = 0;