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: Thu, 21 Mar 2024 08:55:13 -0700
From: Isaku Yamahata <isaku.yamahata@...el.com>
To: Chao Gao <chao.gao@...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>, erdemaktas@...gle.com,
	Sean Christopherson <seanjc@...gle.com>,
	Sagi Shahar <sagis@...gle.com>, Kai Huang <kai.huang@...el.com>,
	chen.bo@...el.com, hang.yuan@...el.com, tina.zhang@...el.com,
	Xiaoyao Li <xiaoyao.li@...el.com>, isaku.yamahata@...ux.intel.com
Subject: Re: [PATCH v19 039/130] KVM: TDX: initialize VM with TDX specific
 parameters

On Wed, Mar 20, 2024 at 02:12:49PM +0800,
Chao Gao <chao.gao@...el.com> wrote:

> >+static void setup_tdparams_cpuids(struct kvm_cpuid2 *cpuid,
> >+				  struct td_params *td_params)
> >+{
> >+	int i;
> >+
> >+	/*
> >+	 * td_params.cpuid_values: The number and the order of cpuid_value must
> >+	 * be same to the one of struct tdsysinfo.{num_cpuid_config, cpuid_configs}
> >+	 * It's assumed that td_params was zeroed.
> >+	 */
> >+	for (i = 0; i < tdx_info->num_cpuid_config; i++) {
> >+		const struct kvm_tdx_cpuid_config *c = &tdx_info->cpuid_configs[i];
> >+		/* KVM_TDX_CPUID_NO_SUBLEAF means index = 0. */
> >+		u32 index = c->sub_leaf == KVM_TDX_CPUID_NO_SUBLEAF ? 0 : c->sub_leaf;
> >+		const struct kvm_cpuid_entry2 *entry =
> >+			kvm_find_cpuid_entry2(cpuid->entries, cpuid->nent,
> >+					      c->leaf, index);
> >+		struct tdx_cpuid_value *value = &td_params->cpuid_values[i];
> >+
> >+		if (!entry)
> >+			continue;
> >+
> >+		/*
> >+		 * tdsysinfo.cpuid_configs[].{eax, ebx, ecx, edx}
> >+		 * bit 1 means it can be configured to zero or one.
> >+		 * bit 0 means it must be zero.
> >+		 * Mask out non-configurable bits.
> >+		 */
> >+		value->eax = entry->eax & c->eax;
> >+		value->ebx = entry->ebx & c->ebx;
> >+		value->ecx = entry->ecx & c->ecx;
> >+		value->edx = entry->edx & c->edx;
> 
> Any reason to mask off non-configurable bits rather than return an error? this
> is misleading to userspace because guest sees the values emulated by TDX module
> instead of the values passed from userspace (i.e., the request from userspace
> isn't done but there is no indication of that to userspace).

Ok, I'll eliminate them.  If user space passes wrong cpuids, TDX module will
return error. I'll leave the error check to the TDX module.


> >+	}
> >+}
> >+
> >+static int setup_tdparams_xfam(struct kvm_cpuid2 *cpuid, struct td_params *td_params)
> >+{
> >+	const struct kvm_cpuid_entry2 *entry;
> >+	u64 guest_supported_xcr0;
> >+	u64 guest_supported_xss;
> >+
> >+	/* Setup td_params.xfam */
> >+	entry = kvm_find_cpuid_entry2(cpuid->entries, cpuid->nent, 0xd, 0);
> >+	if (entry)
> >+		guest_supported_xcr0 = (entry->eax | ((u64)entry->edx << 32));
> >+	else
> >+		guest_supported_xcr0 = 0;
> >+	guest_supported_xcr0 &= kvm_caps.supported_xcr0;
> >+
> >+	entry = kvm_find_cpuid_entry2(cpuid->entries, cpuid->nent, 0xd, 1);
> >+	if (entry)
> >+		guest_supported_xss = (entry->ecx | ((u64)entry->edx << 32));
> >+	else
> >+		guest_supported_xss = 0;
> >+
> >+	/*
> >+	 * PT and CET can be exposed to TD guest regardless of KVM's XSS, PT
> >+	 * and, CET support.
> >+	 */
> >+	guest_supported_xss &=
> >+		(kvm_caps.supported_xss | XFEATURE_MASK_PT | TDX_TD_XFAM_CET);
> >+
> >+	td_params->xfam = guest_supported_xcr0 | guest_supported_xss;
> >+	if (td_params->xfam & XFEATURE_MASK_LBR) {
> >+		/*
> >+		 * TODO: once KVM supports LBR(save/restore LBR related
> >+		 * registers around TDENTER), remove this guard.
> >+		 */
> >+#define MSG_LBR	"TD doesn't support LBR yet. KVM needs to save/restore IA32_LBR_DEPTH properly.\n"
> >+		pr_warn(MSG_LBR);
> 
> Drop the pr_warn() because userspace can trigger it at will.
> 
> I don't think KVM needs to relay TDX module capabilities to userspace as-is.
> KVM should advertise a feature only if both TDX module's and KVM's support
> are in place. if KVM masked out LBR and PERFMON, it should be a problem of
> userspace and we don't need to warn here.

Makes sense. Drop those message and don't advertise those features to user
space.
-- 
Isaku Yamahata <isaku.yamahata@...el.com>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ