[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3960cd4d-9dc6-9f74-720e-4aa6c1ca1d21@linux.intel.com>
Date: Tue, 8 Jun 2021 16:04:46 -0700
From: "Kuppuswamy, Sathyanarayanan"
<sathyanarayanan.kuppuswamy@...ux.intel.com>
To: Dave Hansen <dave.hansen@...el.com>,
Peter Zijlstra <peterz@...radead.org>,
Andy Lutomirski <luto@...nel.org>,
Tony Luck <tony.luck@...el.com>,
Dan Williams <dan.j.williams@...el.com>
Cc: Andi Kleen <ak@...ux.intel.com>,
Kirill Shutemov <kirill.shutemov@...ux.intel.com>,
Kuppuswamy Sathyanarayanan <knsathya@...nel.org>,
Raj Ashok <ashok.raj@...el.com>,
Sean Christopherson <seanjc@...gle.com>,
linux-kernel@...r.kernel.org
Subject: Re: [RFC v2-fix-v3 1/1] x86/tdx: Skip WBINVD instruction for TDX
guest
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
Powered by blists - more mailing lists