Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <ec60ed6f-eafc-80eb-affc-3102c5dc3165@intel.com>
Date:   Tue, 19 Apr 2022 15:49:53 -0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.7.0
Content-Language: en-US
To:     Kai Huang <kai.huang@intel.com>,
        Kuppuswamy Sathyanarayanan 
        <sathyanarayanan.kuppuswamy@linux.intel.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
        Dave Hansen <dave.hansen@linux.intel.com>, x86@kernel.org,
        Hans de Goede <hdegoede@redhat.com>,
        Mark Gross <mgross@linux.intel.com>
Cc:     "H . Peter Anvin" <hpa@zytor.com>,
        "Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>,
        Tony Luck <tony.luck@intel.com>,
        Andi Kleen <ak@linux.intel.com>, linux-kernel@vger.kernel.org,
        platform-driver-x86@vger.kernel.org
References: <20220415220109.282834-1-sathyanarayanan.kuppuswamy@linux.intel.com>
 <20220415220109.282834-5-sathyanarayanan.kuppuswamy@linux.intel.com>
 <bd83067542a3519ee4c91f9d50e9bd4fac27e4bb.camel@intel.com>
 <975b5050-2108-9ace-cc71-46f17db0a731@intel.com>
 <f40fe89d9b978d525ed5d56b0679d1c20b10864b.camel@intel.com>
From:   Dave Hansen <dave.hansen@intel.com>
Subject: Re: [PATCH v3 4/4] platform/x86: intel_tdx_attest: Add TDX Guest
 attestation interface driver
In-Reply-To: <f40fe89d9b978d525ed5d56b0679d1c20b10864b.camel@intel.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 4/19/22 15:21, Kai Huang wrote:
> On Tue, 2022-04-19 at 07:13 -0700, Dave Hansen wrote:
>> On 4/19/22 00:47, Kai Huang wrote:
>>>> From security's perspective, attestation is an essential part of TDX.  That
>>> being said, w/o attestation support in TD guest, I guess nobody will seriously
>>> use TD guest.
>> Are you saying you can't think of a single threat model where there's a
>> benefit to running a TDX guest without attestation?  Will TDX only be
>> used in environments where secrets are provisioned to guests on the
>> basis of attestation?
>>
> I don't think anyone should provision secret to a TD before it get attested that
> it is a genuine TD that he/she expected.  If someone does that, he/she takes the
> risk of losing the secret.  Of course if someone just want to try a TD then w/o
> attestation is totally fine.

Yeah, but you said:

	w/o attestation support in TD guest, I guess nobody will
	seriously use TD guest.

I'm trying to get to the bottom of that.  That's a much more broad
statement than something about when it's safe to deploy secrets.

There are lots of secrets deployed in (serious) VMs today.  There are
lots of secrets deployed in (serious) SEV VMs that don't have
attestation.  Yet, the world somehow hasn't come crashing down.

I think it's crazy to say that nobody will deploy secrets to TDX VMs
without attestation.  I think it's a step father into crazy land to say
that no one will "seriously" use TDX guests without attestation.

Let's be honest about this and not live in some fantasy world, please.