linux-kernel - Re: [PATCH] KVM: VMX: Inject #UD if guest tries to execute SEAMCALL or TDCALL

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aO-oIRBhSIZo9mef@google.com>
Date: Wed, 15 Oct 2025 06:56:49 -0700
From: Sean Christopherson <seanjc@...gle.com>
To: dan.j.williams@...el.com
Cc: Paolo Bonzini <pbonzini@...hat.com>, kvm@...r.kernel.org, linux-kernel@...r.kernel.org, 
	Kai Huang <kai.huang@...el.com>, Xiaoyao Li <xiaoyao.li@...el.com>, 
	Rick Edgecombe <rick.p.edgecombe@...el.com>
Subject: Re: [PATCH] KVM: VMX: Inject #UD if guest tries to execute SEAMCALL
 or TDCALL

On Tue, Oct 14, 2025, dan.j.williams@...el.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".