From: Sean Christopherson <seanjc@google.com>
To: dan.j.williams@intel.com
Cc: Paolo Bonzini <pbonzini@redhat.com>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
Kai Huang <kai.huang@intel.com>,
Xiaoyao Li <xiaoyao.li@intel.com>,
Rick Edgecombe <rick.p.edgecombe@intel.com>
Subject: Re: [PATCH] KVM: VMX: Inject #UD if guest tries to execute SEAMCALL or TDCALL
Date: Wed, 15 Oct 2025 06:56:49 -0700 [thread overview]
Message-ID: <aO-oIRBhSIZo9mef@google.com> (raw)
In-Reply-To: <68eee932c6ef_2f89910045@dwillia2-mobl4.notmuch>
On Tue, Oct 14, 2025, dan.j.williams@intel.com wrote:
> Sean Christopherson wrote:
> > Note #3! The aforementioned Trust Domain spec uses confusing pseudocde
> > that says that SEAMCALL will #UD if executed "inSEAM", but "inSEAM"
> > specifically means in SEAM Root Mode, i.e. in the TDX-Module. The long-
> > form description explicitly states that SEAMCALL generates an exit when
> > executed in "SEAM VMX non-root operation".
>
> This one I am not following. Is this mixing the #UD and exit cases? The
> long form says inSEAM generates #UD and that is consistent with the
> "64-Bit Mode Exceptions" table.
I'm calling out that "inSEAM" is confusing. It really should be "in SEAM root
operation" to eliminate ambiguity and to be consistent with how the SDM documents
VMX. For VMX, the SDM describes three states:
1. VMX operation
2. VMX root operation
3. VMX non-root operation
Where #1 is a superset that covers both #2 and #3. The SEAMCALL pseudocode is a
perfect example as it references all three in quick succession:
IF not in VMX operation or inSMM or inSEAM or ((IA32_EFER.LMA & CS.L) == 0)
^^^^^^^^^^^^^
THEN #UD;
ELSIF in VMX non-root operation
^^^^^^^^^^^^^^^^^^^^^^
THEN VMexit(“basic reason” = SEAMCALL,
“VM exit from VMX root operation” (bit 29) = 0);
^^^^^^^^^^^^^^^^^^
ELSIF CPL > 0 or IA32_SEAMRR_MASK.VALID == 0 or “events blocking by MOV-SS”
THEN #GP(0);
The same should hold true for SEAM. E.g. earlier on, the spec explicitly states:
The TD VMs execute in SEAM VMX non-root operation.
as well as:
The physical address bits reserved for encoding TDX private KeyID are meant to
be treated as reserved bits when not in SEAM operation.
Since the TD guest obviously needs to consume its private KeyID, that means that
SEAM also has three states:
1. SEAM operation
2. SEAM VMX root operation
3. SEAM VMX non-root operation
Where #1 is again a superset that covers both #2 and #3.
IMO, any reasonable reading of "inSEAM" is that it is talking about #1, in which
case the pseudocode effectively says that SEAMCALL should #UD if executed in
"SEAM VMX non-root operation", but that's obviously not the case based on the
statement below as well as the TDX-Module code.
Furthermore, the only transitions for"inSEAM" are that it's set to '1' by SEAMCALL,
and cleared to '0' by SEAMRET. That implies that it's _not_ cleared by VM-Enter
from SEAM VMX root operation to SEAM VMX non-root operation, which reinforces my
reading of "inSEAM == SEAM operation".
> For exit it says: "When invoked in SEAM VMX non-root operation or legacy
> VMX non-root operation, this instruction can cause a VM exit".
next prev parent reply other threads:[~2025-10-15 13:56 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-14 23:10 [PATCH] KVM: VMX: Inject #UD if guest tries to execute SEAMCALL or TDCALL Sean Christopherson
2025-10-15 0:22 ` dan.j.williams
2025-10-15 13:56 ` Sean Christopherson [this message]
2025-10-15 15:49 ` dan.j.williams
2025-10-15 1:13 ` Chao Gao
2025-10-15 3:11 ` Xiaoyao Li
2025-10-15 13:20 ` Sean Christopherson
2025-10-15 10:36 ` Xiaoyao Li
2025-10-15 13:57 ` Sean Christopherson
2025-10-15 14:45 ` Xiaoyao Li
2025-10-16 18:28 ` Sean Christopherson
2025-10-15 13:38 ` Binbin Wu
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=aO-oIRBhSIZo9mef@google.com \
--to=seanjc@google.com \
--cc=dan.j.williams@intel.com \
--cc=kai.huang@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=rick.p.edgecombe@intel.com \
--cc=xiaoyao.li@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox