linux-kernel - Re: [RFC PATCH v5 010/104] KVM: TDX: Make TDX VM type supported

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]

Date:   Tue, 15 Mar 2022 14:03:50 -0700
From:   Isaku Yamahata <isaku.yamahata@...il.com>
To:     Kai Huang <kai.huang@...el.com>
Cc:     isaku.yamahata@...el.com, kvm@...r.kernel.org,
        linux-kernel@...r.kernel.org, isaku.yamahata@...il.com,
        Paolo Bonzini <pbonzini@...hat.com>,
        Jim Mattson <jmattson@...gle.com>, erdemaktas@...gle.com,
        Connor Kuehl <ckuehl@...hat.com>,
        Sean Christopherson <seanjc@...gle.com>
Subject: Re: [RFC PATCH v5 010/104] KVM: TDX: Make TDX VM type supported

On Mon, Mar 14, 2022 at 12:08:59PM +1300,
Kai Huang <kai.huang@...el.com> wrote:

> On Fri, 2022-03-04 at 11:48 -0800, isaku.yamahata@...el.com wrote:
> > From: Isaku Yamahata <isaku.yamahata@...el.com>
> > 
> > As first step TDX VM support, return that TDX VM type supported to device
> > model, e.g. qemu.  The callback to create guest TD is vm_init callback for
> > KVM_CREATE_VM.  Add a place holder function and call a function to
> > initialize TDX module on demand because in that callback VMX is enabled by
> > hardware_enable callback (vmx_hardware_enable).
> 
> Should we put this patch at the end of series until all changes required to run
> TD are introduced?  This patch essentially tells userspace KVM is ready to
> support a TD but actually it's not ready.  And this might also cause bisect
> issue I suppose?

The intention is that developers can exercise the new code step-by-step even if
the TDX KVM isn't complete.
How about introducing new config and remove it at the last of the patch series?

diff --git a/arch/x86/kvm/Kconfig b/arch/x86/kvm/Kconfig
index 2b1548da00eb..a3287440aa9e 100644
--- a/arch/x86/kvm/Kconfig
+++ b/arch/x86/kvm/Kconfig
@@ -98,6 +98,20 @@ config X86_SGX_KVM
 
          If unsure, say N.
 
+config X86_TDX_KVM_EXPERIMENTAL
+       bool "EXPERIMENTAL Trust Domian Extensions (TDX) KVM support"
+       default n
+       depends on INTEL_TDX_HOST
+       depends on KVM_INTEL
+       help
+         Enable experimental TDX KVM support.  TDX KVM needs many patches and
+         the patches will be merged step by step, not at once. Even if TDX KVM
+         support is incomplete, enable TDX KVM support so that developper can
+         exercise TDX KVM code.  TODO: Remove this configuration once the
+         (first step of) TDX KVM support is complete.
+
+         If unsure, say N.
+
 config KVM_AMD
        tristate "KVM for AMD processors support"
        depends on KVM
diff --git a/arch/x86/kvm/vmx/tdx.c b/arch/x86/kvm/vmx/tdx.c
index b16e2ed3b204..e31d6902e49c 100644
--- a/arch/x86/kvm/vmx/tdx.c
+++ b/arch/x86/kvm/vmx/tdx.c
@@ -170,7 +170,11 @@ int tdx_module_setup(void)
 
 bool tdx_is_vm_type_supported(unsigned long type)
 {
+#ifdef CONFIG_X86_TDX_KVM_EXPERIMENTAL
        return type == KVM_X86_TDX_VM && READ_ONCE(enable_tdx);
+#else
+       return false;
+#endif
 }
 
 static int __init __tdx_hardware_setup(struct kvm_x86_ops *x86_ops)


-- 
Isaku Yamahata <isaku.yamahata@...il.com>