RE: [RFC RFT PATCH 1/4] hv: Leak pages if set_memory_encrypted() fails
From: Michael Kelley <hidden>
Date: 2024-03-01 19:00:41
Also in:
linux-coco, linux-hyperv, lkml
From: Rick Edgecombe <rick.p.edgecombe@intel.com> Sent: Wednesday, February 21, 2024 6:10 PM
Historically, the preferred Subject prefix for changes to connection.c has been "Drivers: hv: vmbus:", not just "hv:". Sometimes that preference isn't followed, but most of the time it is.
On TDX it is possible for the untrusted host to cause
I'd argue that this is for CoCo VMs in general, not just TDX. I don't know all the failure modes for SEV-SNP, but the code paths you are changing are run in both TDX and SEV-SNP CoCo VMs.
set_memory_encrypted() or set_memory_decrypted() to fail such that an error is returned and the resulting memory is shared. Callers need to take care to handle these errors to avoid returning decrypted (shared) memory to the page allocator, which could lead to functional or security issues. Hyperv could free decrypted/shared pages if set_memory_encrypted() fails.
It's not Hyper-V doing the freeing. Maybe say "VMBus code could free ...."
quoted hunk ↗ jump to hunk
Leak the pages if this happens. Only compile tested. Cc: "K. Y. Srinivasan" <kys@microsoft.com> Cc: Haiyang Zhang <haiyangz@microsoft.com> Cc: Wei Liu <wei.liu@kernel.org> Cc: Dexuan Cui <decui@microsoft.com> Cc: linux-hyperv@vger.kernel.org Signed-off-by: Rick Edgecombe <rick.p.edgecombe@intel.com> --- drivers/hv/connection.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-)diff --git a/drivers/hv/connection.c b/drivers/hv/connection.c index 3cabeeabb1ca..e39493421bbb 100644 --- a/drivers/hv/connection.c +++ b/drivers/hv/connection.c@@ -315,6 +315,7 @@ int vmbus_connect(void) void vmbus_disconnect(void) { + int ret; /* * First send the unload request to the host. */@@ -337,11 +338,13 @@ void vmbus_disconnect(void) vmbus_connection.int_page = NULL; } - set_memory_encrypted((unsigned long)vmbus_connection.monitor_pages[0], 1); - set_memory_encrypted((unsigned long)vmbus_connection.monitor_pages[1], 1); + ret = set_memory_encrypted((unsigned long)vmbus_connection.monitor_pages[0], 1); + ret |= set_memory_encrypted((unsigned long)vmbus_connection.monitor_pages[1], 1); - hv_free_hyperv_page(vmbus_connection.monitor_pages[0]); - hv_free_hyperv_page(vmbus_connection.monitor_pages[1]); + if (!ret) { + hv_free_hyperv_page(vmbus_connection.monitor_pages[0]); + hv_free_hyperv_page(vmbus_connection.monitor_pages[1]); + }
Of course, this will leak the memory for both pages if only one of the set_memory_encrypted() calls fails, but I'm OK with that. It doesn't seem worth the additional complexity to treat each page separately.
vmbus_connection.monitor_pages[0] = NULL; vmbus_connection.monitor_pages[1] = NULL; } -- 2.34.1