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

[Tianyu Lan]

On 12/14/2022 2:08 AM, Michael Kelley (LINUX) wrote:
> From: Tianyu Lan <ltykernel@xxxxxxxxx> 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@xxxxxxxxxxxxx>
> > ---
> >   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.