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: <CAAhR5DHc_1VtVTD=g=q7qvnrK0z57jwD38AoDSDK1buEb5WUDg@mail.gmail.com>
Date: Wed, 20 Aug 2025 16:18:34 -0500
From: Sagi Shahar <sagis@...gle.com>
To: Chenyi Qiang <chenyi.qiang@...el.com>
Cc: linux-kselftest@...r.kernel.org, Paolo Bonzini <pbonzini@...hat.com>, 
	Shuah Khan <shuah@...nel.org>, Sean Christopherson <seanjc@...gle.com>, 
	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>, Ira Weiny <ira.weiny@...el.com>, 
	linux-kernel@...r.kernel.org, kvm@...r.kernel.org
Subject: Re: [PATCH v8 07/30] KVM: selftests: TDX: Use KVM_TDX_CAPABILITIES to
 validate TDs' attribute configuration

On Wed, Aug 13, 2025 at 8:34 AM Chenyi Qiang <chenyi.qiang@...el.com> wrote:
>
>
>
> On 8/8/2025 4:16 AM, Sagi Shahar wrote:
> > From: Ackerley Tng <ackerleytng@...gle.com>
> >
> > This also exercises the KVM_TDX_CAPABILITIES ioctl.
> >
> > Suggested-by: Isaku Yamahata <isaku.yamahata@...el.com>
> > Co-developed-by: Isaku Yamahata <isaku.yamahata@...el.com>
> > Signed-off-by: Isaku Yamahata <isaku.yamahata@...el.com>
> > Signed-off-by: Ackerley Tng <ackerleytng@...gle.com>
> > Signed-off-by: Sagi Shahar <sagis@...gle.com>
> > ---
> >  .../selftests/kvm/lib/x86/tdx/tdx_util.c        | 17 +++++++++++++++++
> >  1 file changed, 17 insertions(+)
> >
> > 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 392d6272d17e..bb074af4a476 100644
> > --- a/tools/testing/selftests/kvm/lib/x86/tdx/tdx_util.c
> > +++ b/tools/testing/selftests/kvm/lib/x86/tdx/tdx_util.c
> > @@ -140,6 +140,21 @@ static void tdx_apply_cpuid_restrictions(struct kvm_cpuid2 *cpuid_data)
> >       }
> >  }
> >
> > +static void tdx_check_attributes(struct kvm_vm *vm, uint64_t attributes)
> > +{
> > +     struct kvm_tdx_capabilities *tdx_cap;
> > +
> > +     tdx_cap = tdx_read_capabilities(vm);
> > +
> > +     /* TDX spec: any bits 0 in supported_attrs must be 0 in attributes */
> > +     TEST_ASSERT_EQ(attributes & ~tdx_cap->supported_attrs, 0);
> > +
> > +     /* TDX spec: any bits 1 in attributes must be 1 in supported_attrs */
> > +     TEST_ASSERT_EQ(attributes & tdx_cap->supported_attrs, attributes);
> > +
> > +     free(tdx_cap);
> > +}
> > +
> >  #define KVM_MAX_CPUID_ENTRIES 256
> >
> >  #define CPUID_EXT_VMX                        BIT(5)
> > @@ -256,6 +271,8 @@ static void tdx_td_init(struct kvm_vm *vm, uint64_t attributes)
> >       memcpy(&init_vm->cpuid, cpuid, kvm_cpuid2_size(cpuid->nent));
> >       free(cpuid);
> >
> > +     tdx_check_attributes(vm, attributes);
> > +
> >       init_vm->attributes = attributes;
> >
> >       tdx_apply_cpuid_restrictions(&init_vm->cpuid);
>
> Do we need to set the init_vm->xfam based on cpuid.0xd and validate it with tdx_cap->supported_xfam?
>
I don't think it's necessary. And according to the TDX spec (TDX
Module Base Spec - 11.8.3. Extended Features Execution Control) the
mapping from CPUID to XFAM is not trivial. Checking attributes makes
sense since some tests use non-default attributes but right now we
don't have any test which uses XFAM features. We can add XFAM support
in the future if it's needed and do the check then.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ