On TDX it is possible for the untrusted host to cause
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.
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]);
+ }
vmbus_connection.monitor_pages[0] = NULL;
vmbus_connection.monitor_pages[1] = NULL;
}
--
2.34.1
On Wed, Feb 21, 2024 at 06:10:03PM -0800, Rick Edgecombe wrote:
> On TDX it is possible for the untrusted host to cause
> 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.
"Hyper-V" throughout.
> 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]);
> + }
This silently leaks the pages if set_memory_encrypted() fails. I think
there should print some warning or error messages here.
Thanks,
Wei.
> vmbus_connection.monitor_pages[0] = NULL;
> vmbus_connection.monitor_pages[1] = NULL;
> }
> --
> 2.34.1
>
On Fri, 2024-03-01 at 09:26 +0000, Wei Liu wrote:
> > Hyperv could free decrypted/shared pages if set_memory_encrypted()
> > fails.
>
> "Hyper-V" throughout.
Ok.
>
> > 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]);
> > + }
>
> This silently leaks the pages if set_memory_encrypted() fails. I
> think
> there should print some warning or error messages here.
Another patch will warn in CPA for the particular case:
https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?h=x86/mm
Do we want a warning in the caller too? It is more robust to other
types of failures in the future I guess.
© 2016 - 2026 Red Hat, Inc.