Messages in this thread |  | | Date | Mon, 26 Dec 2022 12:19:51 +0800 | Subject | Re: [RFC PATCH V2 08/18] x86/hyperv: decrypt vmbus pages for sev-snp enlightened guest | From | Tianyu Lan <> |
| |
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.
|  |