| 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
| ||
|
Message-ID: <ZyJOiPQnBz31qLZ7@google.com>
Date: Wed, 30 Oct 2024 08:19:36 -0700
From: Sean Christopherson <seanjc@...gle.com>
To: Kai Huang <kai.huang@...el.com>
Cc: pbonzini@...hat.com, kvm@...r.kernel.org, rick.p.edgecombe@...el.com,
isaku.yamahata@...el.com, reinette.chatre@...el.com,
binbin.wu@...ux.intel.com, xiaoyao.li@...el.com, yan.y.zhao@...el.com,
adrian.hunter@...el.com, tony.lindgren@...el.com, kristen@...ux.intel.com,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/3] KVM: VMX: Initialize TDX during KVM module load
On Tue, Oct 29, 2024, Kai Huang wrote:
> diff --git a/arch/x86/kvm/Makefile b/arch/x86/kvm/Makefile
> index f9dddb8cb466..fec803aff7ad 100644
> --- a/arch/x86/kvm/Makefile
> +++ b/arch/x86/kvm/Makefile
> @@ -20,6 +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
IMO, INTEL_TDX_HOST should be a KVM Kconfig, e.g. KVM_INTEL_TDX. Forcing the user
to bounce between KVM's menu and the generic menu to enable KVM support for TDX is
kludgy. Having INTEL_TDX_HOST exist before KVM support came along made sense, as
it allowed compile-testing a bunch of code, but I don't think it should be the end
state.
If others disagree, then we should adjust KVM_AMD_SEV in the opposite direction,
because doing different things for SEV vs. TDX is confusing and messy.
> kvm-amd-y += svm/svm.o svm/vmenter.o svm/pmu.o svm/nested.o svm/avic.o
>
> diff --git a/arch/x86/kvm/vmx/main.c b/arch/x86/kvm/vmx/main.c
> index 433ecbd90905..053294939eb1 100644
> --- a/arch/x86/kvm/vmx/main.c
> +++ b/arch/x86/kvm/vmx/main.c
> @@ -6,6 +6,7 @@
> #include "nested.h"
> #include "pmu.h"
> #include "posted_intr.h"
> +#include "tdx.h"
>
> #define VMX_REQUIRED_APICV_INHIBITS \
> (BIT(APICV_INHIBIT_REASON_DISABLED) | \
> @@ -170,6 +171,7 @@ struct kvm_x86_init_ops vt_init_ops __initdata = {
> static void vt_exit(void)
> {
> kvm_exit();
> + tdx_cleanup();
> vmx_exit();
> }
> module_exit(vt_exit);
> @@ -182,6 +184,9 @@ static int __init vt_init(void)
> if (r)
> return r;
>
> + /* tdx_init() has been taken */
> + tdx_bringup();
tdx_module_init()? And honestly, even though Linux doesn't currently support
unloading the TDX module, I think tdx_module_exit() is a perfectly fine name,
because not being able to unload the TDX module and reclaim all of that memory
is a flaw that should be addressed at some point.
> +static enum cpuhp_state tdx_cpuhp_state;
> +
> +static int tdx_online_cpu(unsigned int cpu)
> +{
> + unsigned long flags;
> + int r;
> +
> + /* Sanity check CPU is already in post-VMXON */
> + WARN_ON_ONCE(!(cr4_read_shadow() & X86_CR4_VMXE));
> +
> + /* tdx_cpu_enable() must be called with IRQ disabled */
I don't find this comment helpfu. If it explained _why_ tdx_cpu_enable() requires
IRQs to be disabled, then I'd feel differently, but as is, IMO it doesn't add value.
> + local_irq_save(flags);
> + r = tdx_cpu_enable();
> + local_irq_restore(flags);
> +
> + return r;
> +}
> +
...
> +static int __init __do_tdx_bringup(void)
> +{
> + int r;
> +
> + /*
> + * TDX-specific cpuhp callback to call tdx_cpu_enable() on all
> + * online CPUs before calling tdx_enable(), and on any new
> + * going-online CPU to make sure it is ready for TDX guest.
> + */
> + r = cpuhp_setup_state_cpuslocked(CPUHP_AP_ONLINE_DYN,
> + "kvm/cpu/tdx:online",
> + tdx_online_cpu, NULL);
> + if (r < 0)
> + return r;
> +
> + tdx_cpuhp_state = r;
> +
> + /* tdx_enable() must be called with cpus_read_lock() */
This comment is even less valuable, IMO.
> + r = tdx_enable();
> + if (r)
> + __do_tdx_cleanup();
> +
> + return r;
> +}
> +
> +static int __init __tdx_bringup(void)
> +{
> + int r;
> +
> + if (!enable_ept) {
> + pr_err("Cannot enable TDX with EPT disabled.\n");
Why wait until now to check for EPT? Force enable_tdx to false if enable_ept is
false, don't fail the module load.
> + return -EINVAL;
> + }
> +
> + /*
> + * Enabling TDX requires enabling hardware virtualization first,
> + * as making SEAMCALLs requires CPU being in post-VMXON state.
> + */
> + r = kvm_enable_virtualization();
> + if (r)
> + return r;
> +
> + cpus_read_lock();
> + r = __do_tdx_bringup();
> + cpus_read_unlock();
> +
> + if (r)
> + goto tdx_bringup_err;
> +
> + /*
> + * Leave hardware virtualization enabled after TDX is enabled
> + * successfully. TDX CPU hotplug depends on this.
> + */
> + return 0;
> +tdx_bringup_err:
> + kvm_disable_virtualization();
> + return r;
> +}
> +
> +void tdx_cleanup(void)
> +{
> + if (enable_tdx) {
> + __do_tdx_cleanup();
> + kvm_disable_virtualization();
> + }
> +}
> +
> +void __init tdx_bringup(void)
> +{
> + enable_tdx = enable_tdx && !__tdx_bringup();
Ah. I don't love this approach because it mixes "failure" due to an unsupported
configuration, with failure due to unexpected issues. E.g. if enabling virtualization
fails, loading KVM-the-module absolutely should fail too, not simply disable TDX.
Powered by blists - more mailing lists