From: Sean Christopherson <seanjc@google.com>
To: John Allen <john.allen@amd.com>
Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
pbonzini@redhat.com, weijiang.yang@intel.com,
rick.p.edgecombe@intel.com, x86@kernel.org,
thomas.lendacky@amd.com
Subject: Re: [RFC PATCH] x86/sev-es: Include XSS value in GHCB CPUID request
Date: Fri, 14 Oct 2022 20:27:05 +0000 [thread overview]
Message-ID: <Y0nGGeCK+/FPOZej@google.com> (raw)
In-Reply-To: <20221012204716.204904-1-john.allen@amd.com>
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@amd.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
>
next prev parent reply other threads:[~2022-10-14 20:27 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-12 20:47 [RFC PATCH] x86/sev-es: Include XSS value in GHCB CPUID request John Allen
2022-10-14 20:27 ` Sean Christopherson [this message]
2022-10-24 16:23 ` John Allen
2022-10-24 16:31 ` Tom Lendacky
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y0nGGeCK+/FPOZej@google.com \
--to=seanjc@google.com \
--cc=john.allen@amd.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=rick.p.edgecombe@intel.com \
--cc=thomas.lendacky@amd.com \
--cc=weijiang.yang@intel.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox