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

[Sean Christopherson <seanjc@google.com>]

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.

> > > +{
> > > +	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.