From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.5 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2190AC433E1 for ; Wed, 15 Jul 2020 00:51:33 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id F1B242071B for ; Wed, 15 Jul 2020 00:51:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726820AbgGOAvc (ORCPT ); Tue, 14 Jul 2020 20:51:32 -0400 Received: from mga17.intel.com ([192.55.52.151]:64198 "EHLO mga17.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726472AbgGOAvc (ORCPT ); Tue, 14 Jul 2020 20:51:32 -0400 IronPort-SDR: HVlwtCL7MGIt67/iZAqzhv1z6RBt0gQmlH++jzugDgJAO3/hYkJIi41KIwyuoWgFp1mCuzii+E KS85+eNkfuHw== X-IronPort-AV: E=McAfee;i="6000,8403,9682"; a="129143297" X-IronPort-AV: E=Sophos;i="5.75,353,1589266800"; d="scan'208";a="129143297" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Jul 2020 17:51:31 -0700 IronPort-SDR: tZVuTxoxURNmLUGrV7HsCtXOT6Rvob3NShDSo/T/sjerUQA38u1yg9gE0BUuA9hlrv5+qEKEgi sZlkEU4jhzzQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.75,353,1589266800"; d="scan'208";a="268801804" Received: from sjchrist-coffee.jf.intel.com (HELO linux.intel.com) ([10.54.74.152]) by fmsmga007.fm.intel.com with ESMTP; 14 Jul 2020 17:51:30 -0700 Date: Tue, 14 Jul 2020 17:51:30 -0700 From: Sean Christopherson To: Dave Hansen Cc: Pawan Gupta , Borislav Petkov , Thomas Gleixner , Ingo Molnar , x86@kernel.org, "H. Peter Anvin" , Paolo Bonzini , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , Tony Luck , "Gomez Iglesias, Antonio" , Andy Lutomirski , Peter Zijlstra , Fenghua Yu , Dave Hansen , Vincenzo Frascino , Josh Poimboeuf , Anthony Steinhauser , Mike Rapoport , Mark Gross , Waiman Long , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, Jonathan Corbet Subject: Re: [PATCH] x86/bugs/multihit: Fix mitigation reporting when KVM is not in use Message-ID: <20200715005130.GE14404@linux.intel.com> References: <267631f4db4fd7e9f7ca789c2efaeab44103f68e.1594689154.git.pawan.kumar.gupta@linux.intel.com> <20200714014540.GH29725@linux.intel.com> <099d6985-9e9f-1d9f-7098-58a9e26e4450@intel.com> <20200714191759.GA7116@guptapadev.amr> <20200714210442.GA10488@guptapadev.amr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-doc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org On Tue, Jul 14, 2020 at 02:20:59PM -0700, Dave Hansen wrote: > On 7/14/20 2:04 PM, Pawan Gupta wrote: > >> I see three inputs and four possible states (sorry for the ugly table, > >> it was this or a spreadsheet :): > >> > >> X86_FEATURE_VMX CONFIG_KVM_* hpage split Result Reason > >> N x x Not Affected No VMX > >> Y N x Not affected No KVM This line item is pointless, the relevant itlb_multihit_show_state() implementation depends on CONFIG_KVM_INTEL. The !KVM_INTEL version simply prints ""Processor vulnerable". > >> Y Y Y Mitigated hpage split > >> Y Y N Vulnerable > > Thank you. > > > > Just a note... for the last 2 cases kernel wont know about "hpage split" > > mitigation until KVM is loaded. So for these cases reporting at boot > > will be "Vulnerable" and would change to "Mitigated" once KVM is loaded > > and deploys the mitigation. This is the current behavior. > > That's OK with me, because it's actually pretty closely tied to reality. > You are literally "vulnerable" until you've committed to a mitigation > and that doesn't happen until KVM is loaded. Not that it really matters since itlb_multihit_show_state() reflects current state, but loading KVM doesn't commit to a mitigation. KVM's nx_huge_pages module param is writable by root, e.g. the mitigation can be turned off while KVM is loaded and even while guests are running. To do the above table, KVM will also need to update itlb_multihit_kvm_mitigation when it is unloaded, which seems rather silly. That's partly why I suggested keying off CR4.VMXE as it doesn't require poking directly into KVM. E.g. the entire fix becomes: diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c index ed54b3b21c39..4452df7f332d 100644 --- a/arch/x86/kernel/cpu/bugs.c +++ b/arch/x86/kernel/cpu/bugs.c @@ -1447,7 +1447,12 @@ static ssize_t l1tf_show_state(char *buf) static ssize_t itlb_multihit_show_state(char *buf) { - if (itlb_multihit_kvm_mitigation) + if (!boot_cpu_has(X86_FEATURE_MSR_IA32_FEAT_CTL) || + !boot_cpu_has(X86_FEATURE_VMX)) + return sprintf(buf, "KVM: Mitigation: VMX unsupported\n"); + else if (!(cr4_read_shadow() & X86_CR4_VMXE)) + return sprintf(buf, "KVM: Mitigation: VMX disabled\n"); + else if (itlb_multihit_kvm_mitigation) return sprintf(buf, "KVM: Mitigation: Split huge pages\n"); else return sprintf(buf, "KVM: Vulnerable\n");