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=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no 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 6275AC47082 for ; Tue, 8 Jun 2021 23:04:52 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4DC6761364 for ; Tue, 8 Jun 2021 23:04:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235114AbhFHXGo (ORCPT ); Tue, 8 Jun 2021 19:06:44 -0400 Received: from mga18.intel.com ([134.134.136.126]:11143 "EHLO mga18.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234272AbhFHXGn (ORCPT ); Tue, 8 Jun 2021 19:06:43 -0400 IronPort-SDR: 7OiaCEtoo0lbCt8zqgMS8xlOaXr3zQAAeSg71orLTIjqDIMMzAlpLNvglNEklNJq/wPkirYHha eKMWL7wfwwOw== X-IronPort-AV: E=McAfee;i="6200,9189,10009"; a="192281785" X-IronPort-AV: E=Sophos;i="5.83,259,1616482800"; d="scan'208";a="192281785" Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Jun 2021 16:04:48 -0700 IronPort-SDR: Est3ejA8vtQVDnCdKwCG8sRhCrVLBWJ2jf32J9EBP2uQmIuRVa6JJh4XtKecE/csgN8zq1D4vt gvWGbw6ho51g== X-IronPort-AV: E=Sophos;i="5.83,259,1616482800"; d="scan'208";a="402236905" Received: from dabarred-mobl1.amr.corp.intel.com (HELO skuppusw-mobl5.amr.corp.intel.com) ([10.254.185.80]) by orsmga003-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Jun 2021 16:04:48 -0700 Subject: Re: [RFC v2-fix-v3 1/1] x86/tdx: Skip WBINVD instruction for TDX guest To: Dave Hansen , Peter Zijlstra , Andy Lutomirski , Tony Luck , Dan Williams Cc: Andi Kleen , Kirill Shutemov , Kuppuswamy Sathyanarayanan , Raj Ashok , Sean Christopherson , linux-kernel@vger.kernel.org References: <20210608213527.739474-1-sathyanarayanan.kuppuswamy@linux.intel.com> From: "Kuppuswamy, Sathyanarayanan" Message-ID: <3960cd4d-9dc6-9f74-720e-4aa6c1ca1d21@linux.intel.com> Date: Tue, 8 Jun 2021 16:04:46 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 6/8/21 3:53 PM, Dave Hansen wrote: > On 6/8/21 3:36 PM, Kuppuswamy, Sathyanarayanan wrote: >> On 6/8/21 3:17 PM, Dave Hansen wrote: >>> On 6/8/21 2:35 PM, Kuppuswamy Sathyanarayanan wrote: > > A kernel driver using WBINVD will "sigfault"? I'm not sure what that > means. How does the kernel "sigfault"? Sorry, un-supported #VE is handled similar to #GP fault. > >> In this patch we only create exception for ACPI sleep driver code. If >> commit log is confusing, I can remove information about other unsupported >> feature (with WBINVD usage). > > Yes, the changelog is horribly confusing. But simply removing this > information is insufficient to rectify the deficiency. I will remove all the unrelated information from this commit log. As long as commit log *only* talks and handles the exception for ACPI sleep driver, it should be acceptable for you right? I will also add a note about, if any other feature with WBINVD usage is enabled, it would lead to #GP fault. > > I've lost trust that due diligence will be performed on this series on > its own. I've seen too many broken promises and too many holes. > > Here's what I want to see: a list of all of the unique call sites for > WBINVD in the kernel. I want a written down methodology for how the > list of call sites was generated. I want to see an item-by-item list of > why those call sites are unreachable with the TDX guest code. It might > be because they've been patched in this patch, or the driver has been > disabled, or because the TDX architecture spec would somehow prohibit > the situation where it might be needed. But, there needs to be a list, > and you have to show your work. If you refer to code from this series > as helping to prevent WBINVD, then it has to be earlier in this series, > not in some other series and not later in this series. > > Just eyeballing it, there are ~50 places in the kernel that need auditing. > > Right now, we mostly have indiscriminate hand-waving about this not > being a problem. It's a hard NAK from me on this patch until this audit > is in place. > -- Sathyanarayanan Kuppuswamy Linux Kernel Developer