Received: by 2002:a4a:311b:0:0:0:0:0 with SMTP id k27-v6csp4783558ooa; Tue, 14 Aug 2018 10:29:39 -0700 (PDT) X-Google-Smtp-Source: AA+uWPzy+j/Ga3Uj940mLIiDsOHNS4hNJZcezkIhBegxS4VvEC1A0Dkh6M+Py9hHh8pnnvqwTJvL X-Received: by 2002:a63:ce12:: with SMTP id y18-v6mr21948977pgf.144.1534267779012; Tue, 14 Aug 2018 10:29:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1534267778; cv=none; d=google.com; s=arc-20160816; b=QCwPBC6yzTltVBQcS/WTRMD19lDaE3cKky8PVsorCHsSfn7BHKWknQ21rtKWsbfaxx xUfNH2qY+AEzzyX1A/G2HRDpYlHcsVjMGHFgvzMMOKjQg6EYpI5TB/5FsFFPnhfkr1c/ A6Wx/d382o+K8ib8TmGA+RSpAWpXzV8H7i877CkubB7kLYeYeRrw72X0/A3QYKxpeMK/ 62esKC4S1HuPHlTFCsKrVLNCjwlhetloGuyrO2a8umiaYesNs9mITteY4yUoG9NN0lv/ 1L14raKtJZd7E/3Bfwt53mX7nFpGAP2tY/5LgPY3Ykvv3mOvDRYU0lhg4r03sA366O9G dDvw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :in-reply-to:message-id:date:subject:cc:to:from :arc-authentication-results; bh=WAdFUZ5+o0xu3niuA1dSeNgIDpAlFuqNzDOMCiiBffQ=; b=BSe1JqNmug2Y3srCyOA7KNkJ0YkxY8pFJ5+1M8y/S+WZfXVsN16R8WA6SM7kIQ7/yU AfqMhuYEP8L0ET8tXLtdx0K8n3f1WumUZ+YMwI6TG2NPQVjaEQmIc0AAAQpwJlc5Epjx 228GseZ3+NdS5g5LR21QSTzTxXuWhlwUSMzcko8xyJFmMK/4qESUf5X2g9vQMkV9oF1R qJZzmeSP18wTNywT81llVpEIIFz/dC9N0C/jQ5B1+lta6lTfALTlZ/5HZ2dy4j9mk0yj jgKg5fh9Jj9FWohQIcJzdOzgbndV/QLjamhLFF1VzNEYRZohguBtHjufFYN0707+WxEW eJKA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m9-v6si18072646pgq.172.2018.08.14.10.29.24; Tue, 14 Aug 2018 10:29:38 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388675AbeHNUPU (ORCPT + 99 others); Tue, 14 Aug 2018 16:15:20 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:52426 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2387886AbeHNUPT (ORCPT ); Tue, 14 Aug 2018 16:15:19 -0400 Received: from localhost (unknown [194.244.16.108]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id 05714BDB; Tue, 14 Aug 2018 17:27:11 +0000 (UTC) From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Paolo Bonzini , Peter Zijlstra , Nicolai Stange , Thomas Gleixner Subject: [PATCH 4.18 65/79] x86/KVM/VMX: Introduce per-host-cpu analogue of l1tf_flush_l1d Date: Tue, 14 Aug 2018 19:17:24 +0200 Message-Id: <20180814171340.601636387@linuxfoundation.org> X-Mailer: git-send-email 2.18.0 In-Reply-To: <20180814171336.799314117@linuxfoundation.org> References: <20180814171336.799314117@linuxfoundation.org> User-Agent: quilt/0.65 X-stable: review MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 4.18-stable review patch. If anyone has any objections, please let me know. ------------------ From: Nicolai Stange Part of the L1TF mitigation for vmx includes flushing the L1D cache upon VMENTRY. L1D flushes are costly and two modes of operations are provided to users: "always" and the more selective "conditional" mode. If operating in the latter, the cache would get flushed only if a host side code path considered unconfined had been traversed. "Unconfined" in this context means that it might have pulled in sensitive data like user data or kernel crypto keys. The need for L1D flushes is tracked by means of the per-vcpu flag l1tf_flush_l1d. KVM exit handlers considered unconfined set it. A vmx_l1d_flush() subsequently invoked before the next VMENTER will conduct a L1d flush based on its value and reset that flag again. Currently, interrupts delivered "normally" while in root operation between VMEXIT and VMENTER are not taken into account. Part of the reason is that these don't leave any traces and thus, the vmx code is unable to tell if any such has happened. As proposed by Paolo Bonzini, prepare for tracking all interrupts by introducing a new per-cpu flag, "kvm_cpu_l1tf_flush_l1d". It will be in strong analogy to the per-vcpu ->l1tf_flush_l1d. A later patch will make interrupt handlers set it. For the sake of cache locality, group kvm_cpu_l1tf_flush_l1d into x86' per-cpu irq_cpustat_t as suggested by Peter Zijlstra. Provide the helpers kvm_set_cpu_l1tf_flush_l1d(), kvm_clear_cpu_l1tf_flush_l1d() and kvm_get_cpu_l1tf_flush_l1d(). Make them trivial resp. non-existent for !CONFIG_KVM_INTEL as appropriate. Let vmx_l1d_flush() handle kvm_cpu_l1tf_flush_l1d in the same way as l1tf_flush_l1d. Suggested-by: Paolo Bonzini Suggested-by: Peter Zijlstra Signed-off-by: Nicolai Stange Signed-off-by: Thomas Gleixner Reviewed-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman --- arch/x86/include/asm/hardirq.h | 23 +++++++++++++++++++++++ arch/x86/kvm/vmx.c | 17 +++++++++++++---- 2 files changed, 36 insertions(+), 4 deletions(-) --- a/arch/x86/include/asm/hardirq.h +++ b/arch/x86/include/asm/hardirq.h @@ -7,6 +7,9 @@ typedef struct { u16 __softirq_pending; +#if IS_ENABLED(CONFIG_KVM_INTEL) + u8 kvm_cpu_l1tf_flush_l1d; +#endif unsigned int __nmi_count; /* arch dependent */ #ifdef CONFIG_X86_LOCAL_APIC unsigned int apic_timer_irqs; /* arch dependent */ @@ -58,4 +61,24 @@ extern u64 arch_irq_stat_cpu(unsigned in extern u64 arch_irq_stat(void); #define arch_irq_stat arch_irq_stat + +#if IS_ENABLED(CONFIG_KVM_INTEL) +static inline void kvm_set_cpu_l1tf_flush_l1d(void) +{ + __this_cpu_write(irq_stat.kvm_cpu_l1tf_flush_l1d, 1); +} + +static inline void kvm_clear_cpu_l1tf_flush_l1d(void) +{ + __this_cpu_write(irq_stat.kvm_cpu_l1tf_flush_l1d, 0); +} + +static inline bool kvm_get_cpu_l1tf_flush_l1d(void) +{ + return __this_cpu_read(irq_stat.kvm_cpu_l1tf_flush_l1d); +} +#else /* !IS_ENABLED(CONFIG_KVM_INTEL) */ +static inline void kvm_set_cpu_l1tf_flush_l1d(void) { } +#endif /* IS_ENABLED(CONFIG_KVM_INTEL) */ + #endif /* _ASM_X86_HARDIRQ_H */ --- a/arch/x86/kvm/vmx.c +++ b/arch/x86/kvm/vmx.c @@ -9729,14 +9729,23 @@ static void vmx_l1d_flush(struct kvm_vcp * 'always' */ if (static_branch_likely(&vmx_l1d_flush_cond)) { - bool flush_l1d = vcpu->arch.l1tf_flush_l1d; + bool flush_l1d; /* - * Clear the flush bit, it gets set again either from - * vcpu_run() or from one of the unsafe VMEXIT - * handlers. + * Clear the per-vcpu flush bit, it gets set again + * either from vcpu_run() or from one of the unsafe + * VMEXIT handlers. */ + flush_l1d = vcpu->arch.l1tf_flush_l1d; vcpu->arch.l1tf_flush_l1d = false; + + /* + * Clear the per-cpu flush bit, it gets set again from + * the interrupt handlers. + */ + flush_l1d |= kvm_get_cpu_l1tf_flush_l1d(); + kvm_clear_cpu_l1tf_flush_l1d(); + if (!flush_l1d) return; }