Re: [PATCH v8 5/5] x86/tdx: Add Quote generation support

["Nakajima, Jun" <jun.nakajima@intel.com>]

> On Jul 22, 2022, at 2:18 PM, Sathyanarayanan Kuppuswamy <sathyanarayanan.kuppuswamy@linux.intel.com> wrote:
> 
> + Jun
> 
> On 7/22/22 12:13 PM, Dave Hansen wrote:
>> On 7/22/22 12:05, Isaku Yamahata wrote:
>>>> So, the quote portion of this is basically a bidirectional blob sender.
>>>> It's to send a blob between guest userspace to host userspace.
>>>> 
>>>> Do we *REALLY* need specific driver functionality for this?  For
>>>> instance, is there no existing virtio device that can send blobs back
>>>> and forth?
>>> It's virtio-vsock.  If virtio-vsock is available, the communication works.
>>> However, some users would like to disable virtio-vsock on their environment for
>>> some reasons.  Even virtio at all.  Especially for confidential computing use
>>> case.  It's their choice.  It can't be assumed that virtio is available.
>>> 
>>> The goal is VMM-agnostic (but TDX-specific) interface for that.
>> 
>> You're basically saying that every confidential computing technology
>> should have its own host user <-> guest kernel <-> guest user ABI.
>> That's insanity.  If we do this, we need *one* interface that says "talk
>> to the hypervisor" that's common for all hypervisors and hardware
>> vendors, or at least more than *one*.
>> 
>> We don't need a way to talk to hypervisors for Intel systems and another
>> for AMD and yet another on whatever.
> 
> For cases where your platform does not want to support or enable the generic
> interface (like vsock), isn't it better to have a fallback approach? I am not
> saying we should have such an ABI for all cases. But attestation is a must-have
> feature for the TDX guest, and we want to support it in all TD guest platforms.
> I think the GHCI ABI is added to meet this requirement.
> 
> Jun/Isaku, if you are aware of the exact requirement for this hypercall, please
> share it. Also let us know your comments on this topic.
> 

Yes, a quote is a blob, and there are special things with that because of the nature (i.e. the essential data for verification).
1. It’s small (e.g. 4KB or something like that).
2. One-time. It shouldn't change even if you repeat the request (GetQuote).
3. Need to be available in minimal/early runtime environments, including pre-boot, e.g. guest BIOS, no user-space yet.

In my view, getting a quote using virtio-vsock is overkill both for the host and the guest. The host may not want the guests to talk directly to the host because of security concerns. 

This particular patch allows the guest user-space to get a quote for an attestation service, and it can be used for the first attestation of the guest, i.e. when the guest kernel has not been verified yet. It’s useful when getting the key for the guest confidential data, such as user data volume, before mounting the volume. Can we use virtio-vsock there? Yes, but, again, overkill and limited availability.

Since we don’t want to allow the user-space to use a hypercall (to get a quote), I think some sort of driver should be needed there. So, I think this driver is useful at least as a fallback when virtio-vsock is not available. 


--- 
Jun