Received-SPF: pass (google.com: domain of linux-kernel+bounces-99781-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Message-ID: <d861ff54-e3db-4beb-999b-05e60c99945d@linux.intel.com>
Date: Mon, 11 Mar 2024 19:56:10 -0700
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 1/5] Drivers: hv: vmbus: Leak pages if
 set_memory_encrypted() fails
Content-Language: en-US
To: mhklinux@outlook.com, rick.p.edgecombe@intel.com, kys@microsoft.com,
 haiyangz@microsoft.com, wei.liu@kernel.org, decui@microsoft.com,
 gregkh@linuxfoundation.org, davem@davemloft.net, edumazet@google.com,
 kuba@kernel.org, pabeni@redhat.com, kirill.shutemov@linux.intel.com,
 dave.hansen@linux.intel.com, linux-kernel@vger.kernel.org,
 linux-hyperv@vger.kernel.org, netdev@vger.kernel.org,
 linux-coco@lists.linux.dev
Cc: elena.reshetova@intel.com
References: <20240311161558.1310-1-mhklinux@outlook.com>
 <20240311161558.1310-2-mhklinux@outlook.com>
From: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
In-Reply-To: <20240311161558.1310-2-mhklinux@outlook.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Hi,

On 3/11/24 9:15 AM, mhkelley58@gmail.com wrote:
> From: Rick Edgecombe <rick.p.edgecombe@intel.com>
>
> In CoCo VMs 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.
>
> VMBus code could free decrypted pages if set_memory_encrypted()/decrypted()
> fails. Leak the pages if this happens.
>
> Signed-off-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
> Signed-off-by: Michael Kelley <mhklinux@outlook.com>
> ---
LGTM

Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
>  drivers/hv/connection.c | 29 ++++++++++++++++++++++-------
>  1 file changed, 22 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/hv/connection.c b/drivers/hv/connection.c
> index 3cabeeabb1ca..f001ae880e1d 100644
> --- a/drivers/hv/connection.c
> +++ b/drivers/hv/connection.c
> @@ -237,8 +237,17 @@ int vmbus_connect(void)
>  				vmbus_connection.monitor_pages[0], 1);
>  	ret |= set_memory_decrypted((unsigned long)
>  				vmbus_connection.monitor_pages[1], 1);
> -	if (ret)
> +	if (ret) {
> +		/*
> +		 * If set_memory_decrypted() fails, the encryption state
> +		 * of the memory is unknown. So leak the memory instead
> +		 * of risking returning decrypted memory to the free list.
> +		 * For simplicity, always handle both pages the same.
> +		 */
> +		vmbus_connection.monitor_pages[0] = NULL;
> +		vmbus_connection.monitor_pages[1] = NULL;
>  		goto cleanup;
> +	}
>  
>  	/*
>  	 * Set_memory_decrypted() will change the memory contents if
> @@ -337,13 +346,19 @@ 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);
> +	if (vmbus_connection.monitor_pages[0]) {
> +		if (!set_memory_encrypted(
> +			(unsigned long)vmbus_connection.monitor_pages[0], 1))
> +			hv_free_hyperv_page(vmbus_connection.monitor_pages[0]);
> +		vmbus_connection.monitor_pages[0] = NULL;
> +	}
>  
> -	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;
> +	if (vmbus_connection.monitor_pages[1]) {
> +		if (!set_memory_encrypted(
> +			(unsigned long)vmbus_connection.monitor_pages[1], 1))
> +			hv_free_hyperv_page(vmbus_connection.monitor_pages[1]);
> +		vmbus_connection.monitor_pages[1] = NULL;
> +	}
>  }
>  
>  /*

-- 
Sathyanarayanan Kuppuswamy
Linux Kernel Developer