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

[Peter Fang <peter.fang@intel.com>]

On Tue, Jul 21, 2026 at 09:43:57AM -0700, Edgecombe, Rick P wrote:
> 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.

Hmm good point. So maybe treat this more like a bug than an attack. Then
the direction is clearer.

I went back to my debate with AI and found what spooked me:

        "Letting untrusted input reach a WARN is a well-known
        anti-pattern precisely because of panic_on_warn — it's why
        syzkaller treats any WARN as a bug."
                -> but this is more of a bug than an untrusted input

        "'Fail hard to defend against the attacking host' buys you zero
        additional protection, while adding log-spam and a
        benign-misconfig panic vector."
                -> but there is also no point in limping along

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

Yes it's directly from the TDX module. So maybe it's more of a question
of how loud this failure should be. There is already a:

        pr_err("Failed to allocate Quote buffer\n");

... later if buffer allocation fails, so the user will see something in
dmesg. But maybe it's too subtle...

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

Sounds good to me. Thanks for providing more background.

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

Another consideration I had at the time was that this happens before
attestation. And not being able to do attestation felt like a big enough
red flag (I'm assuming something in the guest would scream). So that led
me to think that perhaps a warn would be too noisy. But I'm good with
following the TDX policy and just warn.

I think this tilts the scale towards keeping the warn. Let me know if
anyone thinks otherwise. Thanks for the discussion!