linux-kernel - Re: [PATCH v11 13/21] KVM: selftests: Add helpers to init TDX memory and finalize VM

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] [day] [month] [year] [list]

Message-ID: <aPu2NsDuU08UQ5N4@google.com>
Date: Fri, 24 Oct 2025 10:24:06 -0700
From: Sean Christopherson <seanjc@...gle.com>
To: Sagi Shahar <sagis@...gle.com>
Cc: Ira Weiny <ira.weiny@...el.com>, linux-kselftest@...r.kernel.org, 
	Paolo Bonzini <pbonzini@...hat.com>, Shuah Khan <shuah@...nel.org>, 
	Ackerley Tng <ackerleytng@...gle.com>, Ryan Afranji <afranji@...gle.com>, 
	Andrew Jones <ajones@...tanamicro.com>, Isaku Yamahata <isaku.yamahata@...el.com>, 
	Erdem Aktas <erdemaktas@...gle.com>, Rick Edgecombe <rick.p.edgecombe@...el.com>, 
	Roger Wang <runanwang@...gle.com>, Binbin Wu <binbin.wu@...ux.intel.com>, 
	Oliver Upton <oliver.upton@...ux.dev>, "Pratik R. Sampat" <pratikrajesh.sampat@....com>, 
	Reinette Chatre <reinette.chatre@...el.com>, Chao Gao <chao.gao@...el.com>, 
	Chenyi Qiang <chenyi.qiang@...el.com>, linux-kernel@...r.kernel.org, kvm@...r.kernel.org
Subject: Re: [PATCH v11 13/21] KVM: selftests: Add helpers to init TDX memory
 and finalize VM

On Fri, Oct 24, 2025, Sagi Shahar wrote:
> On Fri, Oct 24, 2025 at 11:02 AM Sean Christopherson <seanjc@...gle.com> wrote:
> >
> > On Thu, Oct 23, 2025, Sagi Shahar wrote:
> > > On Wed, Oct 15, 2025 at 11:25 AM Ira Weiny <ira.weiny@...el.com> wrote:
> > > >
> > > > Sagi Shahar wrote:
> > > > > From: Ackerley Tng <ackerleytng@...gle.com>
> > > > >
> > > >
> > > > [snip]
> > > >
> > > > > diff --git a/tools/testing/selftests/kvm/lib/x86/tdx/tdx_util.c b/tools/testing/selftests/kvm/lib/x86/tdx/tdx_util.c
> > > > > index 2551b3eac8f8..53cfadeff8de 100644
> > > > > --- a/tools/testing/selftests/kvm/lib/x86/tdx/tdx_util.c
> > > > > +++ b/tools/testing/selftests/kvm/lib/x86/tdx/tdx_util.c
> > > > > @@ -270,3 +270,61 @@ void vm_tdx_init_vm(struct kvm_vm *vm, uint64_t attributes)
> > > > >
> > > > >       free(init_vm);
> > > > >  }
> > > > > +
> > > >
> > > > [snip]
> > > >
> > > > > +
> > > > > +void vm_tdx_finalize(struct kvm_vm *vm)
> > > >
> > > > Why is this not a new kvm_arch_vm_finalize_vcpu() call?
> > >
> > > What do you mean?
> >
> > Ira is pointing out that upstream now has kvm_arch_vm_finalize_vcpus(), so you
> > can (and I agree, should) implement that for x86.c, and do vm_tdx_finalize() from
> > there (based on the VM shape) instead of requiring the caller to manually finalize
> > the TD.
> >
> > Unlike SEV, where userspace can manipulate guest state prior to LAUNCH, TDX guest
> > state is unreachable from time zero, i.e. there is unlikely to be many (any?) use
> > cases where a selftest wants to do something between creating vCPUs and finalizing
> > the TD.
> 
> There are actually a few use cases for calling vm_tdx_finalize
> seperately from the create phase. One such case is when a user wants
> to add additional memslots for testing shared memory conversions.

Why does creating memslots need to be done before finalizing the TD?  The extra
memslots shouldn't _need_ to be included in the initial image, and I don't recall
anything in the kernel that prevents adding a memslot after the TD is initialized.

> Another one is installing interrupt handlers. But these are probably
> rare enough that they can call __vm_create() and vm_vcpu_add()
> manually instead of using the wrapper

Hmm, for installing interrupt handlers, we could handle that by adding a guest
variant, e.g. so that the guest can install/remove exception handlers after
the initial image is finalized.  We probably want that anyways, otherwise tests
would be unable to manipulate handlers throughout a test.

In fact, it's tempting to kill off vm_install_exception_handler() in x86 entirely,
but that's probably not worth the churn (and some tests would be made more complex).