Received: by 2002:a25:e74b:0:0:0:0:0 with SMTP id e72csp2045299ybh; Tue, 14 Jul 2020 14:14:00 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyO/ZEgKIy6WA478M+YrrBLbwpWmtuv6HOqiYEVLqWCwrral+i5yg+Ztq/I6wEaTK4vnw5f X-Received: by 2002:a50:e617:: with SMTP id y23mr5000256edm.47.1594761240477; Tue, 14 Jul 2020 14:14:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1594761240; cv=none; d=google.com; s=arc-20160816; b=mMNo6iLKYtvfPAbeUNhVOEqDdAprfCBSEvPHjzjeDUaOBebLWd5U/80C6GKet6daLb 5uS4zZPEFmdj7bP3w3KuzQteRgxgHoTtLcoTakU6UAiYdF7Jl+fPDKxESAOq/P3apqLy 2J65W/sczMK63IE+4aWauF0/Ojarb+xXbLNlu9+dLzvr7yHawFY376PXg3OZtL/LxGp6 Vp+d/ZPfz7cR2l6xR7MsJZZcXWTF9Az2rZ40/kwqSsYzaXqOxOnQ+OrGWqohF3JCE0fm +mm/ZwRBMECTMmIRmr7DWOMRqLZJAJ43mTRVxaasx1xh7A2O9IyECmWGchUWXHjWt46A wetQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :ironport-sdr:ironport-sdr; bh=4pWHOTmin2KHI1+jxNcNL2KLoMqnXxX4olCbTe2bnwA=; b=ibDbeyaPGOYckwsj3nJolXHcvoNKgjoM8AO8C4OJY0neUoYw2C0krMf7p1WYc5Dn3P gU+G8r/uqb+rGFte5kOiYwY0os8u4YVkwd/BISdpdv+gYtYq4gxdvR8nsJsJv7KqvAz4 dC6jxlBep5TbdUFkkG7/q1mbQM1/yOqxiYlFyaJ6OxXG9hO7Mo/zGHQhDLaPqIcHQglM iOwnWAcSXqaKe6uFHzMStKwSEEX2awX7x+ey+LTTwwAOPghotwDcPXhpeZphBH54uy89 AWJI2Q3XKncHezVglPgeu+gttXAXltpPWxl5cVS/mi49SIPWpXEgk/qba0QjGiXAPx7E uMvQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id f2si11061380edq.124.2020.07.14.14.13.37; Tue, 14 Jul 2020 14:14:00 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728199AbgGNVKm (ORCPT + 99 others); Tue, 14 Jul 2020 17:10:42 -0400 Received: from mga18.intel.com ([134.134.136.126]:65232 "EHLO mga18.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726803AbgGNVKm (ORCPT ); Tue, 14 Jul 2020 17:10:42 -0400 IronPort-SDR: 6+s5bw4acGe2g7m+sK+NOJt3pf2ba2KvZwJEV+Eo+yf1P2P9vC7GeBE88It1S6OJ6baFctxNHX nCST0cCqfniA== X-IronPort-AV: E=McAfee;i="6000,8403,9682"; a="136484542" X-IronPort-AV: E=Sophos;i="5.75,352,1589266800"; d="scan'208";a="136484542" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Jul 2020 14:10:37 -0700 IronPort-SDR: mRkXTVY8FE9FnwRg6IsgUfaEkC8DpaHNd/BqpxFkylEOZPR+MChTgPVgZnEjcYDnaI8aFQ4di4 gSW6y8eJWUvA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.75,352,1589266800"; d="scan'208";a="390597299" Received: from guptapadev.jf.intel.com (HELO guptapadev.amr) ([10.54.74.188]) by fmsmga001.fm.intel.com with ESMTP; 14 Jul 2020 14:10:34 -0700 Date: Tue, 14 Jul 2020 14:04:42 -0700 From: Pawan Gupta To: Dave Hansen Cc: Sean Christopherson , 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: <20200714210442.GA10488@guptapadev.amr> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jul 14, 2020 at 12:54:26PM -0700, Dave Hansen wrote: > On 7/14/20 12:17 PM, Pawan Gupta wrote: > > On Tue, Jul 14, 2020 at 07:57:53AM -0700, Dave Hansen wrote: > >> Let's stick to things which are at least static per reboot. Checking > >> for X86_FEATURE_VMX or even CONFIG_KVM_INTEL seems like a good stopping > >> point. "Could this kernel run a naughty guest?" If so, report > >> "Vulnerable". It's the same as Meltdown: "Could this kernel run > >> untrusted code?" If so, report "Vulnerable". > > > > Thanks, These are good inputs. So what I need to add is a boot time > > check for VMX feature and report "Vulnerable" or "Not > > affected(VMX disabled)". > > > > Are you suggesting to not change the reporting when KVM deploys the > > "Split huge pages" mitigation? Is this because VMX can still be used by > > other VMMs? > > > > The current mitigation reporting is very specific to KVM: > > > > - "KVM: Vulnerable" > > - "KVM: Mitigation: Split huge pages" > > > > As the kernel doesn't know about the mitigation state of out-of-tree > > VMMs can we add VMX reporting to always say vulnerable when VMX is > > enabled: > > > > - "VMX: Vulnerable, KVM: Vulnerable" > > - "VMX: Vulnerable, KVM: Mitigation: Split huge pages" > > > > And if VMX is disabled report: > > > > - "VMX: Not affected(VMX disabled)" > > 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 > 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. Thanks, Pawan