Re: [PATCH v2 16/17] KVM: TDX: Add in-kernel Quote generation

[Peter Fang]

On Fri, Jul 10, 2026 at 07:48:02AM -0700, Sean Christopherson wrote:
> On Fri, Jul 10, 2026, Peter Fang wrote:
> > On Wed, Jul 08, 2026 at 02:37:55PM -0700, Sean Christopherson wrote:
> > > On Thu, Jun 18, 2026, Xu Yilun wrote:
> > > And is keying off tdx_quote_enabled() and only tdx_quote_enabled() backwards
> > > compatible?  How do we know that cutting userspace out of the loop wont' break
> > > anything?
> > 
> > Yeah this needs explaining:
> > 
> > The guest-observable difference between the two paths is that it sees
> > quotes in different formats (the TDX module uses newer formats of
> > course). And an old guest must be able to continue using its
> > TDVMCALL<GetQuote> interface for quotes. The guest sends the quote to an
> > external verifier to authenticate itself. The verifier (part of the
> > cloud infrastructure) must know how to parse this format. So in other
> > words, it's the verifier that must maintain backward compatibility if it
> > wants to continue accepting old quotes. And it needs to be updated to
> > support newer formats as well.
> 
> Uh, no, that's not how KVM's guest/host ABI works.  Updating the host kernel and
> breaking existing guest is not acceptable.

Yeah I agree there's ABI sensitivity here. I can provide a bit more
context here:

- When you get a quote you don't check it yourself. You pass it to a
  verifier service which does the check. The verifier checks if the
  platform is genuine. It has platform specific knowledge for each new
  platform. So with a new platform these services need to be updated to
  know about the new platform's quote, or attestation will fail for
  these guests.
- There may be platforms that support TDX but have SGX off for various
  reasons. Meaning SGX based attestation won't work and they will only
  support this new type of quote.
- SGX based attestation is very complicated for users. It will likely be
  deprecated long term. This new type of quote simplifies a lot of
  steps.


A risk could be that someone makes a quote verifying service that
supports a new DICE capable platform halfway (SGX only), then the user
does a kernel upgrade and sees their verifications start failing. But
these halfway services would probably come to life after the kernel
support is upstream since DICE capable platforms are not available yet.
So not sure if that's a major concern for regression.

I should call out this is not a zero-risk ABI change and the risks
should have been enumerated. The approach this revision takes is to have
less uABI on the assumption that it will not impact any real users. So
we need to consider whether the simplicity is worth it vs going to
userspace and back. Is it worth considering to have less uABI?  Or would
you rather punt to userspace?  BTW, the quote SEAMCALL does it for a
specifc TD. So putting this new ABI in the TDX host service would
require adding KVM's TD life cycle knowledge. So the "and back" part
probably would fit best as a new KVM TDX ioctl.

> 
> > > > +{
> > > > +	gfn_t gfn_start, gfn_end;
> > > > +	u64 end;
> > > > +
> > > > +	if (!size)
> > > > +		return TDVMCALL_STATUS_INVALID_OPERAND;
> > > > +
> > > > +	if (!PAGE_ALIGNED(gpa) || !PAGE_ALIGNED(size))
> > > > +		return TDVMCALL_STATUS_ALIGN_ERROR;
> > > > +
> > > > +	if (check_add_overflow(gpa, size, &end))
> > > > +		return TDVMCALL_STATUS_INVALID_OPERAND;
> > > > +
> > > > +	gfn_start = gpa_to_gfn(gpa);
> > > > +	gfn_end = gpa_to_gfn(end);
> > > > +
> > > > +	/*
> > > > +	 * Reject if the guest didn't explicitly convert its quote pages to
> > > > +	 * shared.
> > > > +	 */
> > > > +	if (!kvm_range_has_memory_attributes(vcpu->kvm, gfn_start, gfn_end,
> > > > +					     KVM_MEMORY_ATTRIBUTE_PRIVATE, 0))
> > > 
> > > TOCTOU?
> > 
> > I struggled a bit with this actually... I can't just grab
> > kvm->slots_lock here, and dropping kvm->srcu seems bad because the quote
> > will be written to guest memory later. I settled on the idea that the
> > guest should make sure these pages are converted to shared first. If it
> > tries to convert them back to private after this check, before this
> > TDVMCALL returns, then it's kind of a self-inflicted race and I don't
> > see KVM doing any self damage in this case. Not sure if this makes sense
> > to you? Or maybe I should just drop this check and go straight to
> > kvm_vcpu_read_guest()?
> 
> Yes, drop it and rely on uaccess to do the right thing.

Got it, thanks Sean.