linux-kernel - Re: [RFC PATCH] x86/sev-es: Include XSS value in GHCB CPUID request

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:   Fri, 14 Oct 2022 20:27:05 +0000
From:   Sean Christopherson <seanjc@...gle.com>
To:     John Allen <john.allen@....com>
Cc:     kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
        pbonzini@...hat.com, weijiang.yang@...el.com,
        rick.p.edgecombe@...el.com, x86@...nel.org, thomas.lendacky@....com
Subject: Re: [RFC PATCH] x86/sev-es: Include XSS value in GHCB CPUID request

On Wed, Oct 12, 2022, John Allen wrote:
> When a guest issues a cpuid instruction for Fn0000000D_x0B
> (CetUserOffset), KVM will intercept and need to access the guest

s/KVM will/the hypervisor may

> XSS value.

Heh, "need" is debatable.

> For SEV-ES, this is encrypted and needs to be
> included in the GHCB to be visible to the hypervisor. The rdmsr
> instruction needs to be called directly as the code may be used in early
> boot in which case the rdmsr wrappers should be avoided as they are
> incompatible with the decompression boot phase.
> 
> Signed-off-by: John Allen <john.allen@....com>
> ---
> This patch is logically part of the SVM guest shadow stack support series seen
> here:
> https://lore.kernel.org/all/20221012203910.204793-1-john.allen@amd.com/
> 
> Sending this patch separately from the main series as it should apply to the
> tip tree as opposed to the kvm tree as this patch is related to guest kernel
> support.
> ---
>  arch/x86/kernel/sev-shared.c | 15 +++++++++++++++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/arch/x86/kernel/sev-shared.c b/arch/x86/kernel/sev-shared.c
> index 3a5b0c9c4fcc..34469fac03f0 100644
> --- a/arch/x86/kernel/sev-shared.c
> +++ b/arch/x86/kernel/sev-shared.c
> @@ -887,6 +887,21 @@ static enum es_result vc_handle_cpuid(struct ghcb *ghcb,
>  		/* xgetbv will cause #GP - use reset value for xcr0 */
>  		ghcb_set_xcr0(ghcb, 1);
>  
> +	if (has_cpuflag(X86_FEATURE_SHSTK) && regs->ax == 0xd) {

IIRC, XCR0 and XSS are only needed for sub-leafs 0 and 1, i.e. this and the code
above don't need to expose XCR0/XSS to the host for ECX > 1.

FWIW, I think it's ridiculous that the guest willingly exposes state to the host,
it's not _that_ difficult to do the math in the guest.

> +		unsigned long lo, hi;
> +		u64 xss;
> +
> +		/*
> +		 * Since vc_handle_cpuid may be used during early boot, the
> +		 * rdmsr wrappers are incompatible and should not be used.
> +		 * Invoke the instruction directly.
> +		 */
> +		asm volatile("rdmsr" : "=a" (lo), "=d" (hi)
> +				    : "c" (MSR_IA32_XSS));

Doesn't __rdmsr() do what you want?  But even that seems unnecessary, isn't the
current XSS available in xfeatures_mask_supervisor()?

> +		xss = (hi << 32) | lo;
> +		ghcb_set_xss(ghcb, xss);
> +	}
> +
>  	ret = sev_es_ghcb_hv_call(ghcb, ctxt, SVM_EXIT_CPUID, 0, 0);
>  	if (ret != ES_OK)
>  		return ret;
> -- 
> 2.34.3
>