--- /dev/null
+From b119019847fbcac36ed1384f166c91f177d070e7 Mon Sep 17 00:00:00 2001
+From: Jim Mattson <jmattson@google.com>
+Date: Thu, 13 Jun 2019 09:16:08 -0700
+Subject: kvm: nVMX: Remove unnecessary sync_roots from handle_invept
+
+From: Jim Mattson <jmattson@google.com>
+
+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 <junaids@google.com>
+Fixes: bfd0a56b90005f ("nEPT: Nested INVEPT")
+Cc: Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
+Cc: Nadav Har'El <nyh@il.ibm.com>
+Cc: Jun Nakajima <jun.nakajima@intel.com>
+Cc: Xinhao Xu <xinhao.xu@intel.com>
+Cc: Yang Zhang <yang.z.zhang@Intel.com>
+Cc: Gleb Natapov <gleb@redhat.com>
+Cc: Paolo Bonzini <pbonzini@redhat.com>
+Reviewed-by Peter Shier <pshier@google.com>
+Reviewed-by: Junaid Shahid <junaids@google.com>
+Signed-off-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/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);
--- /dev/null
+From 118154bdf54ca79e4b5f3ce6d4a8a7c6b7c2c76f Mon Sep 17 00:00:00 2001
+From: Liran Alon <liran.alon@oracle.com>
+Date: Wed, 17 Jul 2019 02:56:58 +0300
+Subject: KVM: SVM: Fix detection of AMD Errata 1096
+
+From: Liran Alon <liran.alon@oracle.com>
+
+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 <brijesh.singh@amd.com>
+Cc: Sean Christopherson <sean.j.christopherson@intel.com>
+Cc: Paolo Bonzini <pbonzini@redhat.com>
+Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
+Signed-off-by: Liran Alon <liran.alon@oracle.com>
+Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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);
+ }
+
--- /dev/null
+From f14312a93b34b9350dc33ff0b4215c24f4c82617 Mon Sep 17 00:00:00 2001
+From: Enrico Weigelt <info@metux.net>
+Date: Thu, 25 Jul 2019 21:06:03 +0200
+Subject: platform/x86: pcengines-apuv2: use KEY_RESTART for front button
+
+From: Enrico Weigelt <info@metux.net>
+
+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 <info@metux.net>
+Fixes: f8eb0235f659 ("x86: pcengines apuv2 gpio/leds/keys platform driver")
+Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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,
--- /dev/null
+From 9452fbf5c6cf5f470e0748fe7a14a683e7765f7a Mon Sep 17 00:00:00 2001
+From: Steffen Dirkwinkel <s.dirkwinkel@beckhoff.com>
+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 <s.dirkwinkel@beckhoff.com>
+
+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 <s.dirkwinkel@beckhoff.com>
+Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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"),
projects / thirdparty / kernel / stable-queue.git / commitdiff
