Re: [RFC PATCH V2 08/18] x86/hyperv: decrypt vmbus pages for sev-snp enlightened guest

[Tianyu Lan <ltykernel@gmail.com>]

On 12/14/2022 2:08 AM, Michael Kelley (LINUX) wrote:
> From: Tianyu Lan <ltykernel@gmail.com> Sent: Friday, November 18, 2022 7:46 PM
>>
> 
> The Subject prefix for this patch should be "Drivers: hv: vmbus:"

Sure. Will update in the next version.

> 
>> Vmbus int, synic and post message pages are shared with hypervisor
>> and so decrypt these pages in the sev-snp guest.
>>
>> Signed-off-by: Tianyu Lan <tiala@microsoft.com>
>> ---
>>   drivers/hv/connection.c | 13 +++++++++++++
>>   drivers/hv/hv.c         | 32 +++++++++++++++++++++++++++++++-
>>   2 files changed, 44 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/hv/connection.c b/drivers/hv/connection.c
>> index 9dc27e5d367a..43141225ea15 100644
>> --- a/drivers/hv/connection.c
>> +++ b/drivers/hv/connection.c
>> @@ -215,6 +215,15 @@ int vmbus_connect(void)
>>   		(void *)((unsigned long)vmbus_connection.int_page +
>>   			(HV_HYP_PAGE_SIZE >> 1));
>>
>> +	if (hv_isolation_type_snp() || hv_isolation_type_en_snp()) {
> 
> This decryption should be done only for a fully enlightened SEV-SNP
> guest, not for a vTOM guest.
> 
>> +		ret = set_memory_decrypted((unsigned long)
>> +				vmbus_connection.int_page, 1);
>> +		if (ret)
>> +			goto cleanup;
> 
> This cleanup path doesn't work correctly.  It calls
> vmbus_disconnect(), which will try to re-encrypt the memory.
> But if the original decryption failed, re-encrypting is the wrong
> thing to do.
> 
> It looks like this same bug exists in current code if the decryption
> of the monitor pages fails or if just one of the original memory
> allocations fails.  vmbus_disconnect() doesn't know whether it
> should re-encrypt the pages.

Agree. It's necessary to handle decryption failure case by case in stead 
of re-encryting all pages. Will fix this in the next version. Thanks to 
point out.