lkml.org 
[lkml]   [2022]   [Oct]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [RFC PATCH] x86/sev-es: Include XSS value in GHCB CPUID request
From
On 10/14/2022 3:27 PM, Sean Christopherson wrote:
> 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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fall%2F20221012203910.204793-1-john.allen%40amd.com%2F&amp;data=05%7C01%7Cjohn.allen%40amd.com%7C2ed48fc57d2247f809ed08daae227f2d%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638013760436182289%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=OIO3X5EQdTazOozvCHIF9E2tT%2B6aMqarmkA8o41wJ7M%3D&amp;reserved=0
>>
>> 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.

That makes sense to me. I think given that the XSS code here is tied in
with the SVM shadow stack patches, I'll submit a separate patch to first
address only exposing XCR0 for sub-leafs 0 and 1. Then I'll address XSS in
the next version of the SVM shadow stack patches.

>
>> + 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()?

Yes, I think you're right. That should make this change a lot more palatable.

Thanks,
John

>
>> + 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
>>

\
 
 \ /
  Last update: 2022-10-24 20:04    [W:0.050 / U:0.744 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site