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;
IronPort-SDR: 2MTUcjlbQ4ojpHzQMKpJIHi9fyXm0HVx6iqdb+zM1IJEhlHEwKCsc0mJ/df5Na3+ZcvgJl/Tzr
 eAt0imU0LM+g==
IronPort-SDR: jFzuCrbarKH2l5etqdYvkXLFpiSuobIgylq4Nl/71ddc5yuctmlS/Vdyn/XaFkHh49I7q/bN+K
 N1yaoDAKonmw==
Date:   Wed, 31 Mar 2021 20:28:27 -0700
From:   Andi Kleen <ak@linux.intel.com>
To:     Dave Hansen <dave.hansen@intel.com>
Cc:     "Kuppuswamy, Sathyanarayanan" 
        <sathyanarayanan.kuppuswamy@linux.intel.com>,
        Sean Christopherson <seanjc@google.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Andy Lutomirski <luto@kernel.org>,
        Kirill Shutemov <kirill.shutemov@linux.intel.com>,
        Kuppuswamy Sathyanarayanan <knsathya@kernel.org>,
        Dan Williams <dan.j.williams@intel.com>,
        Raj Ashok <ashok.raj@intel.com>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 1/1] x86/tdx: Handle MWAIT, MONITOR and WBINVD
Message-ID: <20210401032827.GI1285835@tassilo.jf.intel.com>
References: <2FE32855-EA5D-44E4-AACC-25E9B1476547@amacapital.net>
 <e62cfd0ae90de435e6819979d9027f76d835a22a.1617224710.git.sathyanarayanan.kuppuswamy@linux.intel.com>
 <YGTvSvr2T2v3t3XA@google.com>
 <5d961c25-3dee-4a5d-4bba-a97d157a5a49@intel.com>
 <YGTyWUQbxVZeeko+@google.com>
 <d8078f5d-735c-2b0f-98eb-663be2118762@intel.com>
 <ef49222a-8ffc-dacc-4f21-3bd1ef13a2ac@linux.intel.com>
 <b175f08d-2930-158d-8543-fe6a7f6aaf12@intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <b175f08d-2930-158d-8543-fe6a7f6aaf12@intel.com>
Precedence: bulk

> 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