On Wed, Jun 07, 2023 at 07:24:23AM -0700, Dave Hansen <dave.hansen@xxxxxxxxx> wrote: > On 6/4/23 07:27, Kai Huang wrote: > > TDX introduces a new CPU mode: Secure Arbitration Mode (SEAM). This > > mode runs only the TDX module itself or other code to load the TDX > > module. > > > > The host kernel communicates with SEAM software via a new SEAMCALL > > instruction. This is conceptually similar to a guest->host hypercall, > > except it is made from the host to SEAM software instead. The TDX > > module establishes a new SEAMCALL ABI which allows the host to > > initialize the module and to manage VMs. > > > > Add infrastructure to make SEAMCALLs. The SEAMCALL ABI is very similar > > to the TDCALL ABI and leverages much TDCALL infrastructure. > > > > SEAMCALL instruction causes #GP when TDX isn't BIOS enabled, and #UD > > when CPU is not in VMX operation. Currently, only KVM code mocks with > > "mocks"? Did you mean "mucks"? > > > VMX enabling, and KVM is the only user of TDX. This implementation > > chooses to make KVM itself responsible for enabling VMX before using > > TDX and let the rest of the kernel stay blissfully unaware of VMX. > > > > The current TDX_MODULE_CALL macro handles neither #GP nor #UD. The > > kernel would hit Oops if SEAMCALL were mistakenly made w/o enabling VMX > > first. Architecturally, there is no CPU flag to check whether the CPU > > is in VMX operation. Also, if a BIOS were buggy, it could still report > > valid TDX private KeyIDs when TDX actually couldn't be enabled. > > I'm not sure this is a great justification. If the BIOS is lying to the > OS, we _should_ oops. > > How else can this happen other than silly kernel bugs. It's OK to oops > in the face of silly kernel bugs. TDX KVM + reboot can hit #UD. On reboot, VMX is disabled (VMXOFF) via syscore.shutdown callback. However, guest TD can be still running to issue SEAMCALL resulting in #UD. Or we can postpone the change and make the TDX KVM patch series carry a patch for it. -- Isaku Yamahata <isaku.yamahata@xxxxxxxxx>
