From: Greg Kroah-Hartman Date: Tue, 17 Sep 2019 13:24:20 +0000 (+0200) Subject: 5.2-stable patches X-Git-Tag: v4.14.145~14 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=f7b1ffc970033fca23615ccc8b157e3f431d67e9;p=thirdparty%2Fkernel%2Fstable-queue.git 5.2-stable patches added patches: kvm-nvmx-remove-unnecessary-sync_roots-from-handle_invept.patch kvm-svm-fix-detection-of-amd-errata-1096.patch platform-x86-pcengines-apuv2-use-key_restart-for-front-button.patch platform-x86-pmc_atom-add-cb4063-beckhoff-automation-board-to-critclk_systems-dmi-table.patch --- diff --git a/queue-5.2/kvm-nvmx-remove-unnecessary-sync_roots-from-handle_invept.patch b/queue-5.2/kvm-nvmx-remove-unnecessary-sync_roots-from-handle_invept.patch new file mode 100644 index 00000000000..8c2eb905685 --- /dev/null +++ b/queue-5.2/kvm-nvmx-remove-unnecessary-sync_roots-from-handle_invept.patch @@ -0,0 +1,62 @@ +From b119019847fbcac36ed1384f166c91f177d070e7 Mon Sep 17 00:00:00 2001 +From: Jim Mattson +Date: Thu, 13 Jun 2019 09:16:08 -0700 +Subject: kvm: nVMX: Remove unnecessary sync_roots from handle_invept + +From: Jim Mattson + +commit b119019847fbcac36ed1384f166c91f177d070e7 upstream. + +When L0 is executing handle_invept(), the TDP MMU is active. Emulating +an L1 INVEPT does require synchronizing the appropriate shadow EPT +root(s), but a call to kvm_mmu_sync_roots in this context won't do +that. Similarly, the hardware TLB and paging-structure-cache entries +associated with the appropriate shadow EPT root(s) must be flushed, +but requesting a TLB_FLUSH from this context won't do that either. + +How did this ever work? KVM always does a sync_roots and TLB flush (in +the correct context) when transitioning from L1 to L2. That isn't the +best choice for nested VM performance, but it effectively papers over +the mistakes here. + +Remove the unnecessary operations and leave a comment to try to do +better in the future. + +Reported-by: Junaid Shahid +Fixes: bfd0a56b90005f ("nEPT: Nested INVEPT") +Cc: Xiao Guangrong +Cc: Nadav Har'El +Cc: Jun Nakajima +Cc: Xinhao Xu +Cc: Yang Zhang +Cc: Gleb Natapov +Cc: Paolo Bonzini +Reviewed-by Peter Shier +Reviewed-by: Junaid Shahid +Signed-off-by: Jim Mattson +Signed-off-by: Paolo Bonzini +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kvm/vmx/nested.c | 8 +++----- + 1 file changed, 3 insertions(+), 5 deletions(-) + +--- a/arch/x86/kvm/vmx/nested.c ++++ b/arch/x86/kvm/vmx/nested.c +@@ -4708,13 +4708,11 @@ static int handle_invept(struct kvm_vcpu + + switch (type) { + case VMX_EPT_EXTENT_GLOBAL: ++ case VMX_EPT_EXTENT_CONTEXT: + /* +- * TODO: track mappings and invalidate +- * single context requests appropriately ++ * TODO: Sync the necessary shadow EPT roots here, rather than ++ * at the next emulated VM-entry. + */ +- case VMX_EPT_EXTENT_CONTEXT: +- kvm_mmu_sync_roots(vcpu); +- kvm_make_request(KVM_REQ_TLB_FLUSH, vcpu); + break; + default: + BUG_ON(1); diff --git a/queue-5.2/kvm-svm-fix-detection-of-amd-errata-1096.patch b/queue-5.2/kvm-svm-fix-detection-of-amd-errata-1096.patch new file mode 100644 index 00000000000..aac387b1171 --- /dev/null +++ b/queue-5.2/kvm-svm-fix-detection-of-amd-errata-1096.patch @@ -0,0 +1,122 @@ +From 118154bdf54ca79e4b5f3ce6d4a8a7c6b7c2c76f Mon Sep 17 00:00:00 2001 +From: Liran Alon +Date: Wed, 17 Jul 2019 02:56:58 +0300 +Subject: KVM: SVM: Fix detection of AMD Errata 1096 + +From: Liran Alon + +commit 118154bdf54ca79e4b5f3ce6d4a8a7c6b7c2c76f upstream. + +When CPU raise #NPF on guest data access and guest CR4.SMAP=1, it is +possible that CPU microcode implementing DecodeAssist will fail +to read bytes of instruction which caused #NPF. This is AMD errata +1096 and it happens because CPU microcode reading instruction bytes +incorrectly attempts to read code as implicit supervisor-mode data +accesses (that is, just like it would read e.g. a TSS), which are +susceptible to SMAP faults. The microcode reads CS:RIP and if it is +a user-mode address according to the page tables, the processor +gives up and returns no instruction bytes. In this case, +GuestIntrBytes field of the VMCB on a VMEXIT will incorrectly +return 0 instead of the correct guest instruction bytes. + +Current KVM code attemps to detect and workaround this errata, but it +has multiple issues: + +1) It mistakenly checks if guest CR4.SMAP=0 instead of guest CR4.SMAP=1, +which is required for encountering a SMAP fault. + +2) It assumes SMAP faults can only occur when guest CPL==3. +However, in case guest CR4.SMEP=0, the guest can execute an instruction +which reside in a user-accessible page with CPL<3 priviledge. If this +instruction raise a #NPF on it's data access, then CPU DecodeAssist +microcode will still encounter a SMAP violation. Even though no sane +OS will do so (as it's an obvious priviledge escalation vulnerability), +we still need to handle this semanticly correct in KVM side. + +Note that (2) *is* a useful optimization, because CR4.SMAP=1 is an easy +triggerable condition and guests usually enable SMAP together with SMEP. +If the vCPU has CR4.SMEP=1, the errata could indeed be encountered onlt +at guest CPL==3; otherwise, the CPU would raise a SMEP fault to guest +instead of #NPF. We keep this condition to avoid false positives in +the detection of the errata. + +In addition, to avoid future confusion and improve code readbility, +include details of the errata in code and not just in commit message. + +Fixes: 05d5a4863525 ("KVM: SVM: Workaround errata#1096 (insn_len maybe zero on SMAP violation)") +Cc: Singh Brijesh +Cc: Sean Christopherson +Cc: Paolo Bonzini +Reviewed-by: Boris Ostrovsky +Signed-off-by: Liran Alon +Reviewed-by: Brijesh Singh +Signed-off-by: Paolo Bonzini +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kvm/svm.c | 42 +++++++++++++++++++++++++++++++++++------- + 1 file changed, 35 insertions(+), 7 deletions(-) + +--- a/arch/x86/kvm/svm.c ++++ b/arch/x86/kvm/svm.c +@@ -7116,13 +7116,41 @@ static int nested_enable_evmcs(struct kv + + static bool svm_need_emulation_on_page_fault(struct kvm_vcpu *vcpu) + { +- bool is_user, smap; +- +- is_user = svm_get_cpl(vcpu) == 3; +- smap = !kvm_read_cr4_bits(vcpu, X86_CR4_SMAP); ++ unsigned long cr4 = kvm_read_cr4(vcpu); ++ bool smep = cr4 & X86_CR4_SMEP; ++ bool smap = cr4 & X86_CR4_SMAP; ++ bool is_user = svm_get_cpl(vcpu) == 3; + + /* +- * Detect and workaround Errata 1096 Fam_17h_00_0Fh ++ * Detect and workaround Errata 1096 Fam_17h_00_0Fh. ++ * ++ * Errata: ++ * When CPU raise #NPF on guest data access and vCPU CR4.SMAP=1, it is ++ * possible that CPU microcode implementing DecodeAssist will fail ++ * to read bytes of instruction which caused #NPF. In this case, ++ * GuestIntrBytes field of the VMCB on a VMEXIT will incorrectly ++ * return 0 instead of the correct guest instruction bytes. ++ * ++ * This happens because CPU microcode reading instruction bytes ++ * uses a special opcode which attempts to read data using CPL=0 ++ * priviledges. The microcode reads CS:RIP and if it hits a SMAP ++ * fault, it gives up and returns no instruction bytes. ++ * ++ * Detection: ++ * We reach here in case CPU supports DecodeAssist, raised #NPF and ++ * returned 0 in GuestIntrBytes field of the VMCB. ++ * First, errata can only be triggered in case vCPU CR4.SMAP=1. ++ * Second, if vCPU CR4.SMEP=1, errata could only be triggered ++ * in case vCPU CPL==3 (Because otherwise guest would have triggered ++ * a SMEP fault instead of #NPF). ++ * Otherwise, vCPU CR4.SMEP=0, errata could be triggered by any vCPU CPL. ++ * As most guests enable SMAP if they have also enabled SMEP, use above ++ * logic in order to attempt minimize false-positive of detecting errata ++ * while still preserving all cases semantic correctness. ++ * ++ * Workaround: ++ * To determine what instruction the guest was executing, the hypervisor ++ * will have to decode the instruction at the instruction pointer. + * + * In non SEV guest, hypervisor will be able to read the guest + * memory to decode the instruction pointer when insn_len is zero +@@ -7133,11 +7161,11 @@ static bool svm_need_emulation_on_page_f + * instruction pointer so we will not able to workaround it. Lets + * print the error and request to kill the guest. + */ +- if (is_user && smap) { ++ if (smap && (!smep || is_user)) { + if (!sev_guest(vcpu->kvm)) + return true; + +- pr_err_ratelimited("KVM: Guest triggered AMD Erratum 1096\n"); ++ pr_err_ratelimited("KVM: SEV Guest triggered AMD Erratum 1096\n"); + kvm_make_request(KVM_REQ_TRIPLE_FAULT, vcpu); + } + diff --git a/queue-5.2/platform-x86-pcengines-apuv2-use-key_restart-for-front-button.patch b/queue-5.2/platform-x86-pcengines-apuv2-use-key_restart-for-front-button.patch new file mode 100644 index 00000000000..2dc6cdf5bbf --- /dev/null +++ b/queue-5.2/platform-x86-pcengines-apuv2-use-key_restart-for-front-button.patch @@ -0,0 +1,32 @@ +From f14312a93b34b9350dc33ff0b4215c24f4c82617 Mon Sep 17 00:00:00 2001 +From: Enrico Weigelt +Date: Thu, 25 Jul 2019 21:06:03 +0200 +Subject: platform/x86: pcengines-apuv2: use KEY_RESTART for front button + +From: Enrico Weigelt + +commit f14312a93b34b9350dc33ff0b4215c24f4c82617 upstream. + +The keycode KEY_RESTART is more appropriate for the front button, +as most people use it for things like restart or factory reset. + +Signed-off-by: Enrico Weigelt +Fixes: f8eb0235f659 ("x86: pcengines apuv2 gpio/leds/keys platform driver") +Signed-off-by: Andy Shevchenko +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/platform/x86/pcengines-apuv2.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/platform/x86/pcengines-apuv2.c ++++ b/drivers/platform/x86/pcengines-apuv2.c +@@ -93,7 +93,7 @@ struct gpiod_lookup_table gpios_led_tabl + + static struct gpio_keys_button apu2_keys_buttons[] = { + { +- .code = KEY_SETUP, ++ .code = KEY_RESTART, + .active_low = 1, + .desc = "front button", + .type = EV_KEY, diff --git a/queue-5.2/platform-x86-pmc_atom-add-cb4063-beckhoff-automation-board-to-critclk_systems-dmi-table.patch b/queue-5.2/platform-x86-pmc_atom-add-cb4063-beckhoff-automation-board-to-critclk_systems-dmi-table.patch new file mode 100644 index 00000000000..74aba1dc267 --- /dev/null +++ b/queue-5.2/platform-x86-pmc_atom-add-cb4063-beckhoff-automation-board-to-critclk_systems-dmi-table.patch @@ -0,0 +1,39 @@ +From 9452fbf5c6cf5f470e0748fe7a14a683e7765f7a Mon Sep 17 00:00:00 2001 +From: Steffen Dirkwinkel +Date: Tue, 18 Jun 2019 15:31:02 +0200 +Subject: platform/x86: pmc_atom: Add CB4063 Beckhoff Automation board to critclk_systems DMI table + +From: Steffen Dirkwinkel + +commit 9452fbf5c6cf5f470e0748fe7a14a683e7765f7a upstream. + +The CB4063 board uses pmc_plt_clk* clocks for ethernet controllers. This +adds it to the critclk_systems DMI table so the clocks are marked as +CLK_CRITICAL and not turned off. + +Fixes: 648e921888ad ("clk: x86: Stop marking clocks as CLK_IS_CRITICAL") +Signed-off-by: Steffen Dirkwinkel +Signed-off-by: Andy Shevchenko +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/platform/x86/pmc_atom.c | 8 ++++++++ + 1 file changed, 8 insertions(+) + +--- a/drivers/platform/x86/pmc_atom.c ++++ b/drivers/platform/x86/pmc_atom.c +@@ -414,6 +414,14 @@ static const struct dmi_system_id critcl + }, + { + /* pmc_plt_clk* - are used for ethernet controllers */ ++ .ident = "Beckhoff CB4063", ++ .matches = { ++ DMI_MATCH(DMI_SYS_VENDOR, "Beckhoff Automation"), ++ DMI_MATCH(DMI_BOARD_NAME, "CB4063"), ++ }, ++ }, ++ { ++ /* pmc_plt_clk* - are used for ethernet controllers */ + .ident = "Beckhoff CB6263", + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "Beckhoff Automation"), diff --git a/queue-5.2/series b/queue-5.2/series index 3f6784117c7..562d3e42bec 100644 --- a/queue-5.2/series +++ b/queue-5.2/series @@ -77,3 +77,7 @@ iio-adc-stm32-dfsdm-fix-data-type.patch modules-fix-bug-when-load-module-with-rodata-n.patch modules-fix-compile-error-if-don-t-have-strict-module-rwx.patch modules-always-page-align-module-section-allocations.patch +kvm-nvmx-remove-unnecessary-sync_roots-from-handle_invept.patch +kvm-svm-fix-detection-of-amd-errata-1096.patch +platform-x86-pmc_atom-add-cb4063-beckhoff-automation-board-to-critclk_systems-dmi-table.patch +platform-x86-pcengines-apuv2-use-key_restart-for-front-button.patch