Re: [PATCH v2 2/2] virt: tdx-guest: Allocate Quote buffer dynamically

["Edgecombe, Rick P" <rick.p.edgecombe@intel.com>]

On Tue, 2026-07-21 at 06:48 -0700, Dave Hansen wrote:
> > > The host may be untrusted, but it's also a critical part of the system.
> > > Are we sure we want to be completely quiet?
> > > 
> > > I used to see little dmesg warnings about TCP window shenanigans from
> > > random systems on the Internet. Maybe that's not how we do things today,
> > > but if a random dude on the Internet can spew one line to dmesg, is it
> > > that crazy that a bad VMM be able to spew a warning?
> > 
> > That makes sense... I actually argued with AI about this but it kept
> > saying this is kind of like DoSing the guest.

A guest DOSing another guest is relevant, but the host DOSing the guest is not a
threat model we should or even can care about. If userspace or the kernel
decides to kill the guest, that is its prerogative. At most it's a functional
bug and not a security one.

But... doesn't this size come from the TDX module? In which case there is no
hope of defense from anything.

> >  But thinking about it
> > more, tainting the guest is probably the right thing to do... At least
> > the guest sees a big splat about why attestation is failing. I'll remove
> > the __GFP_NOWARN. Thanks.
> 
> This does seem like the kind of high-level TDX policy that we all need
> to be aligned on and probably document somewhere. The basic question is
> whether a TDX guest should be quiet or verbose in the face of host
> malfunction or malfeasance.
> 
> Kirill and Rick, what do you think?

We discussed something similar around the set_memory_en/decrypted() failures.
But that was around whether to panic or just warn. Not be silent. If the host is
mucking around, I think security conscious guests would want to know, and even
have the option to pass panic_on_warn. So yea I think we should assume the
default TDX user is security conscious. "Warn on untrusted host weird behavior"
seems like a good policy.

BUT, is this number coming from the untrusted host or the TDX module? I cant
find TDCS_QUOTE_MAX_SIZE in the docs. If it is coming from the TDX module then
we are not talking about security considerations at all. It's just a functional
"do you want to know if things are failing". Not sure why this one would be
special in that regard. If we think it will fail so often that we don't want a
warning, then we probably need another solution.