linux-kernel - Re: [PATCH v2 10/10] x86/virt/tdx: Don't initialize module that doesn't support NO_RBP

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <66b1aca950924_4fc7294f2@dwillia2-xfh.jf.intel.com.notmuch>
Date: Mon, 5 Aug 2024 21:55:05 -0700
From: Dan Williams <dan.j.williams@...el.com>
To: Kai Huang <kai.huang@...el.com>, <dave.hansen@...el.com>,
	<kirill.shutemov@...ux.intel.com>, <bp@...en8.de>, <tglx@...utronix.de>,
	<peterz@...radead.org>, <mingo@...hat.com>, <hpa@...or.com>,
	<seanjc@...gle.com>, <pbonzini@...hat.com>, <dan.j.williams@...el.com>
CC: <x86@...nel.org>, <kvm@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
	<rick.p.edgecombe@...el.com>, <isaku.yamahata@...el.com>,
	<chao.gao@...el.com>, <binbin.wu@...ux.intel.com>, <kai.huang@...el.com>
Subject: Re: [PATCH v2 10/10] x86/virt/tdx: Don't initialize module that
 doesn't support NO_RBP_MOD feature

Kai Huang wrote:
> Old TDX modules can clobber RBP in the TDH.VP.ENTER SEAMCALL.  However
> RBP is used as frame pointer in the x86_64 calling convention, and
> clobbering RBP could result in bad things like being unable to unwind
> the stack if any non-maskable exceptions (NMI, #MC etc) happens in that
> gap.
> 
> A new "NO_RBP_MOD" feature was introduced to more recent TDX modules to
> not clobber RBP.  This feature is reported in the TDX_FEATURES0 global
> metadata field via bit 18.
> 
> Don't initialize the TDX module if this feature is not supported [1].
> 
> Link: https://lore.kernel.org/all/c0067319-2653-4cbd-8fee-1ccf21b1e646@suse.com/T/#mef98469c51e2382ead2c537ea189752360bd2bef [1]
> Signed-off-by: Kai Huang <kai.huang@...el.com>
> Reviewed-by: Nikolay Borisov <nik.borisov@...e.com>
> ---
> 
> v1 -> v2:
>  - Add tag from Nikolay.
> 
> ---
>  arch/x86/virt/vmx/tdx/tdx.c | 17 +++++++++++++++++
>  arch/x86/virt/vmx/tdx/tdx.h |  1 +
>  2 files changed, 18 insertions(+)
> 
> diff --git a/arch/x86/virt/vmx/tdx/tdx.c b/arch/x86/virt/vmx/tdx/tdx.c
> index 3c19295f1f8f..ec6156728423 100644
> --- a/arch/x86/virt/vmx/tdx/tdx.c
> +++ b/arch/x86/virt/vmx/tdx/tdx.c
> @@ -484,6 +484,18 @@ static int get_tdx_sysinfo(struct tdx_sysinfo *sysinfo)
>  	return get_tdx_tdmr_sysinfo(&sysinfo->tdmr_info);
>  }
>  
> +static int check_module_compatibility(struct tdx_sysinfo *sysinfo)

How about check_features()? Almost everything having to do with TDX
concerns the TDX module, so using "module" in a symbol name rarely adds
any useful context.

> +{
> +	u64 tdx_features0 = sysinfo->module_info.tdx_features0;
> +
> +	if (!(tdx_features0 & TDX_FEATURES0_NO_RBP_MOD)) {
> +		pr_err("NO_RBP_MOD feature is not supported\n");

A user would have no idea with this error message how about something
like:

pr_err("frame pointer (RBP) clobber bug present, upgrade TDX module\n");