linux-kernel - Re: [PATCH V2] x86/Hyper-V: Add SEV negotiate protocol support in Isolation VM

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] [day] [month] [year] [list]

Message-ID: <6b77d369-8f8e-b7f6-76c6-ad27fc21f68d@gmail.com>
Date:   Thu, 9 Jun 2022 15:55:55 +0800
From:   Tianyu Lan <ltykernel@...il.com>
To:     "Michael Kelley (LINUX)" <mikelley@...rosoft.com>,
        KY Srinivasan <kys@...rosoft.com>,
        Haiyang Zhang <haiyangz@...rosoft.com>,
        Stephen Hemminger <sthemmin@...rosoft.com>,
        "wei.liu@...nel.org" <wei.liu@...nel.org>,
        Dexuan Cui <decui@...rosoft.com>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "mingo@...hat.com" <mingo@...hat.com>,
        "bp@...en8.de" <bp@...en8.de>,
        "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
        "x86@...nel.org" <x86@...nel.org>, "hpa@...or.com" <hpa@...or.com>
Cc:     Tianyu Lan <Tianyu.Lan@...rosoft.com>,
        "linux-hyperv@...r.kernel.org" <linux-hyperv@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        vkuznets <vkuznets@...hat.com>,
        "parri.andrea@...il.com" <parri.andrea@...il.com>,
        "thomas.lendacky@....com" <thomas.lendacky@....com>
Subject: Re: [PATCH V2] x86/Hyper-V: Add SEV negotiate protocol support in
 Isolation VM

Hi Michael:
	Thanks for your review.

On 6/8/2022 4:30 AM, Michael Kelley (LINUX) wrote:
>> diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c
>> index 8b392b6b7b93..40b6874accdb 100644
>> --- a/arch/x86/hyperv/hv_init.c
>> +++ b/arch/x86/hyperv/hv_init.c
>> @@ -29,6 +29,7 @@
>>   #include <clocksource/hyperv_timer.h>
>>   #include <linux/highmem.h>
>>   #include <linux/swiotlb.h>
>> +#include <asm/sev.h>
>>
>>   int hyperv_init_cpuhp;
>>   u64 hv_current_partition_id = ~0ull;
>> @@ -70,6 +71,11 @@ static int hyperv_init_ghcb(void)
>>   	ghcb_base = (void **)this_cpu_ptr(hv_ghcb_pg);
>>   	*ghcb_base = ghcb_va;
>>
>> +	/* Negotiate GHCB Version. */
>> +	if (!hv_ghcb_negotiate_protocol())
>> +		hv_ghcb_terminate(SEV_TERM_SET_GEN,
>> +				  GHCB_SEV_ES_PROT_UNSUPPORTED);
>> +
> Negotiating the protocol here is unexpected for me.  The
> function hyperv_init_ghcb() is called for each CPU as it
> initializes, so the static variable ghcb_version will be set
> multiple times.  I can see that setup_ghbc(), which this is
> patterned after, is also called for each CPU during the early
> CPU initialization, which is also a bit weird.  I see two
> problems:
> 
> 1) hv_ghcb_negotiate_protocol() could get called in parallel
> on two different CPUs at the same time, and the Hyper-V
> version modifies global state (the MSR_AMD64_SEV_ES_GHCB
> MSR).  I'm not sure if the sev_es version has the same
> problem.
> 
> 2) The Hyper-V version would get called when taking a CPU
> from on offline state to an online state.  I'm not sure if taking
> CPUs online and offline is allowed in an SNP isolated VM, but
> if it is, then ghcb_version could be modified well after Linux
> initialization, violating the __ro_after_init qualifier on the
> variable.
> 
> Net, it seems like we should find a way to negotiate the
> GHCB version only once at boot time.

Yes, this makes sense and will update.
> 
>> diff --git a/arch/x86/hyperv/ivm.c b/arch/x86/hyperv/ivm.c
>> index 2b994117581e..4b67c4d7c4f5 100644
>> --- a/arch/x86/hyperv/ivm.c
>> +++ b/arch/x86/hyperv/ivm.c
>> @@ -53,6 +53,8 @@ union hv_ghcb {
>>   	} hypercall;
>>   } __packed __aligned(HV_HYP_PAGE_SIZE);
>>
>> +static u16 ghcb_version __ro_after_init;
>> +
> This is same name as the equivalent sev_es variable.  Could this one
> be changed to hv_ghcb_version to avoid any confusion?
> 
>> +static inline void wr_ghcb_msr(u64 val)
>> +{
>> +	u32 low, high;
>> +
>> +	low  = (u32)(val);
>> +	high = (u32)(val >> 32);
>> +
>> +	native_wrmsr(MSR_AMD64_SEV_ES_GHCB, low, high);
> This whole function could be coded as just
> 
> 	native_wrmsrl(MSR_AMD64_SEV_ES_GHCB, val);
> 
> since the "l" version handles breaking the 64-bit argument
> into two 32-bit arguments.

This follows SEV ES code and will update.

> 
>> +}
>> +
>> +static enum es_result ghcb_hv_call(struct ghcb *ghcb, u64 exit_code,
>> +				   u64 exit_info_1, u64 exit_info_2)
> Seems like the function name here should be hv_ghcb_hv_call.
> 
>> @@ -152,8 +229,7 @@ void hv_ghcb_msr_read(u64 msr, u64 *value)
>>   	}
>>
>>   	ghcb_set_rcx(&hv_ghcb->ghcb, msr);
>> -	if (sev_es_ghcb_hv_call(&hv_ghcb->ghcb, false, &ctxt,
>> -				SVM_EXIT_MSR, 0, 0))
>> +	if (ghcb_hv_call(&hv_ghcb->ghcb, SVM_EXIT_MSR, 0, 0))
>>   		pr_warn("Fail to read msr via ghcb %llx.\n", msr);
>>   	else
>>   		*value = (u64)lower_32_bits(hv_ghcb->ghcb.save.rax)
> Since these changes remove the two cases where sev_es_ghcb_hv_call()
> is invoked with the 2nd argument as "false", it seems like there should be
> a follow-on patch to remove that argument and Hyper-V specific hack
> from sev_es_ghcb_hv_call().

OK. Will update.