linux-kernel - Re: [RFC v2-fix-v3 1/1] x86/tdx: Skip WBINVD instruction for TDX guest

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 8 Jun 2021 16:04:14 -0700
From:   Andi Kleen <ak@...ux.intel.com>
To:     Dave Hansen <dave.hansen@...el.com>,
        "Kuppuswamy, Sathyanarayanan" 
        <sathyanarayanan.kuppuswamy@...ux.intel.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:     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

\
> A kernel driver using WBINVD will "sigfault"?  I'm not sure what that
> means.  How does the kernel "sigfault"?

It panics. Please, you know exactly what Sathya meant because you've 
read the code.

>
> 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.

Sorry this is ridiculous. We're not in a make-work project here. We're 
about practical engineering  not make out life artificially complicated.

If that is what is required then the change requests to NOT ignore but 
patch every site were just not practical.

>
> 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.


Okay then we just go back to ignore like the rest of the KVM world.

That's what we had originally and it it's fine because it's exactly what 
KVM does, which is all we want.

It was the sane thing to do and it's still the sane thing to do because 
it has been always done this way.

-And