From: Sean Christopherson <seanjc@google.com>
To: Vishal Annapurve <vannapurve@google.com>
Cc: Dave Hansen <dave.hansen@intel.com>,
Peter Fang <peter.fang@intel.com>,
Rick P Edgecombe <rick.p.edgecombe@intel.com>,
Yilun Xu <yilun.xu@intel.com>,
Elena Reshetova <elena.reshetova@intel.com>,
Binbin Wu <binbin.wu@intel.com>,
"kas@kernel.org" <kas@kernel.org>,
"pbonzini@redhat.com" <pbonzini@redhat.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>
Subject: Re: TDG quote analysis
Date: Wed, 23 Sep 2026 17:18:14 -0700 [thread overview]
Message-ID: <arRsRkn1V8A3xUE5@google.com> (raw)
In-Reply-To: <CAGtprH8syQUQf9PjPe8o6rBFSg+01k=Hb4cvvn3TqED3uWb+yQ@mail.gmail.com>
On Wed, Sep 23, 2026, Vishal Annapurve wrote:
> On Tue, Sep 22, 2026 at 9:09 PM Vishal Annapurve <vannapurve@google.com> wrote:
> >
> > On Mon, Sep 21, 2026 at 4:06 PM Dave Hansen <dave.hansen@intel.com> wrote:
> > >
> > > On 9/21/26 16:00, Peter Fang wrote:
> > > >> is how to hide the fact that someone in the future might think following AMD's
> > > >> lead and putting a precious resource into a tiny microprosser on a slow bus is a
> > > >> fantastic idea.
> > > > As shocking as it sounds, there are actually cloud providers out there
> > > > that are wanting this, or at the very least wanting to see how it goes
> > > > in real deployment. I think memory side channel attacks are a real
> > > > concern for some of them. But yeah this is not great from a performance
> > > > perspective.
> > >
> > > I'll believe it when I see it (on this mailing list).
> > >
> > > If folks want complexity and low performance in the kernel for
> > > side-channel defense, then I'm your guy. I've made half a career out of
> > > it. All that I ask is that they come and ask for it in the open. Here,
> > > please.
> >
> > Google is tracking use cases for deploying S3M-based attestation for
> > both TDX guest workloads and host workloads.
> >
>
> To clarify this statement further and address the discussion from the
> PUCK meeting: Google is tracking use cases for deploying S3M based
> signing of attestation quotes (or S3M-based quoting as referred to in
> this thread) for TDX guest workloads.
Good timing, I was just chatting with Erdem about this. The TL;DR of "why" is
that anything that's done on-CPU is more vulnerable to side channel attacks, so
hyper-paranoid use cases that *also* know the tradeoffs involved may want to
use much slower, but more secure (in theory) S3M signing.
From an upstream perspective, I think we don't care? Or rather, we *shouldn't*
have to care beyond letting the admin flip a TDX Module switch. I'm a-ok letting
end users opt-in to ultra-paranoid mode, with a pile of disclaimers around the
shortcomings and tradeoffs involved. I.e. I don't really care how the quote is
generated, I just don't want to carry any kernel/KVM code to make it less painful
(and it should absolutely be opt-in).
next prev parent reply other threads:[~2026-09-24 0:18 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-16 0:48 TDG quote analysis Edgecombe, Rick P
2026-09-16 18:00 ` Sean Christopherson
2026-09-16 18:49 ` Edgecombe, Rick P
2026-09-16 19:27 ` Sean Christopherson
2026-09-16 22:31 ` Edgecombe, Rick P
2026-09-16 23:00 ` Peter Fang
2026-09-16 23:57 ` Sean Christopherson
2026-09-17 0:56 ` Edgecombe, Rick P
2026-09-17 13:37 ` Sean Christopherson
2026-09-17 18:12 ` Edgecombe, Rick P
2026-09-17 19:57 ` Sean Christopherson
2026-09-17 21:32 ` Edgecombe, Rick P
2026-09-18 0:04 ` Sean Christopherson
2026-09-18 2:39 ` Edgecombe, Rick P
2026-09-18 13:13 ` Sean Christopherson
2026-09-18 18:12 ` Edgecombe, Rick P
2026-09-18 21:32 ` Sean Christopherson
2026-09-21 23:00 ` Peter Fang
2026-09-21 23:06 ` Dave Hansen
2026-09-23 4:09 ` Vishal Annapurve
2026-09-24 0:03 ` Vishal Annapurve
2026-09-24 0:18 ` Sean Christopherson [this message]
2026-09-24 0:44 ` Edgecombe, Rick P
2026-09-24 16:28 ` Sean Christopherson
2026-09-21 23:04 ` Dave Hansen
2026-09-21 23:19 ` Sean Christopherson
2026-09-21 23:36 ` Dave Hansen
2026-09-21 23:46 ` Sean Christopherson
2026-09-22 0:03 ` Dave Hansen
2026-09-22 6:48 ` Reshetova, Elena
2026-09-22 17:07 ` Edgecombe, Rick P
2026-09-23 8:50 ` Reshetova, Elena
2026-09-23 22:50 ` Peter Fang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=arRsRkn1V8A3xUE5@google.com \
--to=seanjc@google.com \
--cc=binbin.wu@intel.com \
--cc=dave.hansen@intel.com \
--cc=elena.reshetova@intel.com \
--cc=kas@kernel.org \
--cc=kvm@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=peter.fang@intel.com \
--cc=rick.p.edgecombe@intel.com \
--cc=vannapurve@google.com \
--cc=yilun.xu@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.