[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210401032827.GI1285835@tassilo.jf.intel.com>
Date: Wed, 31 Mar 2021 20:28:27 -0700
From: Andi Kleen <ak@...ux.intel.com>
To: Dave Hansen <dave.hansen@...el.com>
Cc: "Kuppuswamy, Sathyanarayanan"
<sathyanarayanan.kuppuswamy@...ux.intel.com>,
Sean Christopherson <seanjc@...gle.com>,
Peter Zijlstra <peterz@...radead.org>,
Andy Lutomirski <luto@...nel.org>,
Kirill Shutemov <kirill.shutemov@...ux.intel.com>,
Kuppuswamy Sathyanarayanan <knsathya@...nel.org>,
Dan Williams <dan.j.williams@...el.com>,
Raj Ashok <ashok.raj@...el.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 1/1] x86/tdx: Handle MWAIT, MONITOR and WBINVD
> The hardware (and VMMs and SEAM) have ways of telling the guest kernel
> what is supported: CPUID. If it screws up, and the guest gets an
> unexpected #VE, so be it.
The main reason for disabling stuff is actually that we don't need
to harden it. All these things are potential attack paths.
>
> We don't have all kinds of crazy handling in the kernel's #UD handler
> just in case a CPU mis-enumerates a feature and we get a #UD. We have
> to trust the underlying hardware to be sane. If it isn't, we die a
> horrible death as fast as possible. Why should TDX be any different?
That's what the original patch did -- no unnecessary checks -- but reviewers
keep asking for the extra checks, so Sathya added more. We have the not
unusual problem here that reviewers don't agree among themselves.
-Andi
Powered by blists - more mailing lists