linux-kernel - Re: [PATCH 3/3] KVM: VMX: Initialize TDX during KVM module load

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: <ebf9897e-dda6-4e74-b08b-5d266c6c0c1b@intel.com>
Date: Fri, 1 Nov 2024 11:37:19 +1300
From: "Huang, Kai" <kai.huang@...el.com>
To: Dan Williams <dan.j.williams@...el.com>, "Hansen, Dave"
	<dave.hansen@...el.com>, "seanjc@...gle.com" <seanjc@...gle.com>
CC: "Lindgren, Tony" <tony.lindgren@...el.com>, "Edgecombe, Rick P"
	<rick.p.edgecombe@...el.com>, "binbin.wu@...ux.intel.com"
	<binbin.wu@...ux.intel.com>, "Chatre, Reinette" <reinette.chatre@...el.com>,
	"Li, Xiaoyao" <xiaoyao.li@...el.com>, "Zhao, Yan Y" <yan.y.zhao@...el.com>,
	"Hunter, Adrian" <adrian.hunter@...el.com>, "kvm@...r.kernel.org"
	<kvm@...r.kernel.org>, "pbonzini@...hat.com" <pbonzini@...hat.com>,
	"Yamahata, Isaku" <isaku.yamahata@...el.com>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "kristen@...ux.intel.com"
	<kristen@...ux.intel.com>
Subject: Re: [PATCH 3/3] KVM: VMX: Initialize TDX during KVM module load


> However, I want to provide a counterpoint to this "_ANY_ kernel
> component" dependency on being able to run a TDX guest. TDX Connect like
> SEV-TIO offers device-security provisioning flows that are expected to
> run before any confidential guest is being launched, and theoretically
> may offer services independent of *ever* launching a guest (e.g. PCIe
> link encrcyption without device assignment). So longer term, seamcalls
> without kvm-intel.ko flexibility is useful, but in the near term a
> coarse dependency on kvm-intel.ko is workable.

Thanks for the info.

So it seems we should keep INTEL_TDX_HOST but add a new KVM_INTEL_TDX:

diff --git a/arch/x86/kvm/Kconfig b/arch/x86/kvm/Kconfig
index f09f13c01c6b..bcf4a1243013 100644
--- a/arch/x86/kvm/Kconfig
+++ b/arch/x86/kvm/Kconfig
@@ -126,6 +126,16 @@ config X86_SGX_KVM

           If unsure, say N.

+config KVM_INTEL_TDX
+       bool "Intel Trust Domain Extensions (TDX) support"
+       default y
+       depends on INTEL_TDX_HOST
+       help
+         Provides support for launching Intel Trust Domain Extensions
+         (TDX) confidential VMs on Intel processors.
+
+         If unsure, say N.
+
  config KVM_AMD
         tristate "KVM for AMD processors support"
         depends on KVM && (CPU_SUP_AMD || CPU_SUP_HYGON)
diff --git a/arch/x86/kvm/Makefile b/arch/x86/kvm/Makefile
index fec803aff7ad..a5d362c7b504 100644
--- a/arch/x86/kvm/Makefile
+++ b/arch/x86/kvm/Makefile
@@ -20,7 +20,7 @@ kvm-intel-y           += vmx/vmx.o vmx/vmenter.o 
vmx/pmu_intel.o vmx/vmcs12.o \

  kvm-intel-$(CONFIG_X86_SGX_KVM)        += vmx/sgx.o
  kvm-intel-$(CONFIG_KVM_HYPERV) += vmx/hyperv.o vmx/hyperv_evmcs.o
-kvm-intel-$(CONFIG_INTEL_TDX_HOST)     += vmx/tdx.o
+kvm-intel-$(CONFIG_KVM_INTEL_TDX)      += vmx/tdx.o

  kvm-amd-y              += svm/svm.o svm/vmenter.o svm/pmu.o 
svm/nested.o svm/avic.o

One thing is currently INTEL_TDX_HOST depends on KVM_INTEL (with the 
reason that for now only KVM will use TDX), we can either remove this 
dependency together with the above diff, or we can have another patch in 
the future to remove that when TDX Connect comes near.

I think we can leave this part to the future.

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 007bab9f2a0e..acc5a14dfbbc 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1974,7 +1974,6 @@ config INTEL_TDX_HOST
         bool "Intel Trust Domain Extensions (TDX) host support"
         depends on CPU_SUP_INTEL
         depends on X86_64
-       depends on KVM_INTEL
         depends on X86_X2APIC
         select ARCH_KEEP_MEMBLOCK
         depends on CONTIG_ALLOC