Received-SPF: pass (google.com: domain of linux-kernel+bounces-88989-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
From: Michael Kelley <mhklinux@outlook.com>
To: Rick Edgecombe <rick.p.edgecombe@intel.com>, "kys@microsoft.com"
	<kys@microsoft.com>, "haiyangz@microsoft.com" <haiyangz@microsoft.com>,
	"wei.liu@kernel.org" <wei.liu@kernel.org>, "decui@microsoft.com"
	<decui@microsoft.com>, "linux-hyperv@vger.kernel.org"
	<linux-hyperv@vger.kernel.org>, "gregkh@linuxfoundation.org"
	<gregkh@linuxfoundation.org>, "davem@davemloft.net" <davem@davemloft.net>,
	"edumazet@google.com" <edumazet@google.com>, "kuba@kernel.org"
	<kuba@kernel.org>, "pabeni@redhat.com" <pabeni@redhat.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"kirill.shutemov@linux.intel.com" <kirill.shutemov@linux.intel.com>,
	"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
	"linux-coco@lists.linux.dev" <linux-coco@lists.linux.dev>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
CC: "sathyanarayanan.kuppuswamy@linux.intel.com"
	<sathyanarayanan.kuppuswamy@linux.intel.com>, "elena.reshetova@intel.com"
	<elena.reshetova@intel.com>
Subject: RE: [RFC RFT PATCH 2/4] hv: Track decrypted status in vmbus_gpadl
Thread-Topic: [RFC RFT PATCH 2/4] hv: Track decrypted status in vmbus_gpadl
Thread-Index: AQHaZTRZwlB7r62I/064k+0xwPOwcLEjPmsg
Date: Fri, 1 Mar 2024 19:00:56 +0000
Message-ID:
 <SN6PR02MB4157DDD1AFA071CEA8B5187CD45E2@SN6PR02MB4157.namprd02.prod.outlook.com>
References: <20240222021006.2279329-1-rick.p.edgecombe@intel.com>
 <20240222021006.2279329-3-rick.p.edgecombe@intel.com>
In-Reply-To: <20240222021006.2279329-3-rick.p.edgecombe@intel.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?us-ascii?Q?F8I+50s62m4KLy8StmFJnf7nuj3mJudv5uh+YglFuzbbD1jvG+ol1EEZT6Ms?=
 =?us-ascii?Q?xxvCupYUvfC6I34huxMdnPNUvEUAWHSvpyq8xdjuSS6MCw61w4U8NCYTCUZN?=
 =?us-ascii?Q?/FAp5iiLYBzCqFOdDd92bFNcjRTTYIXvEA9OHf0UXpb7mH57jVwQTU7HH8mx?=
 =?us-ascii?Q?n7EKeMAIniYIFXTsWp4TBKLfMtWYQx4jwPnF2MkvvaGtHhvml4Zzq6vqB+r4?=
 =?us-ascii?Q?mihO3tiIU2neFzLS2E3yDsy5amlG9j3m5SHUZV2raYmxONsyJBal/kKuVDd6?=
 =?us-ascii?Q?v2dUIM+1l69vnjqF3yUM00jpUOZBFk/xc3Uau6GY7fstmd0qALqozXmTdamy?=
 =?us-ascii?Q?s5Ki/kxEcm1CiOxAhX75fPx0U2BVSyCmGCSfPfoOutCC0cRltyOEChgEAS/v?=
 =?us-ascii?Q?qY6mbDuMyX+Kjrdmm6OfvB+V7BtKUXKVd4HFukhbaxnm0p22bpTeYtDDbN5Q?=
 =?us-ascii?Q?TyZV3PoIGLkdSLhq8UwW366V0d6jghUMpGf1wlEpDsr1mwn7fuz6H6sdGCfF?=
 =?us-ascii?Q?dPeovR39pgUTM/7pOxuPWotsZZQ8wz7COtdbesqqJmkpJLSSTpLG4lqIC1p5?=
 =?us-ascii?Q?0Ntpdow+ZISi8iNhcQzpqtIOBOP2JJoG0kLPhGZyNOSik2EEDlc4s/fAl75V?=
 =?us-ascii?Q?cSizSR81O0yZtrz07JPYsQsB1lQy7YceTu7Md9IgzdOnMDg5gqPilewaS9w1?=
 =?us-ascii?Q?szjE8Sxae9YSMbCJRGF4s9eSB02kbS1BS6VQg6iBeEpE3U1fOIpygOWFdKi3?=
 =?us-ascii?Q?n5ZBGLYBt8H5/zKIi1NjccRjnX7Jv8QY82uJXhLYcwGsoBDMjUOTWsqZxWiY?=
 =?us-ascii?Q?Au7wL8QkoQRQEXC8mvFp0akJkxZQopVV0LDDihZ9F7+6BJzTkw5xT3f/SKqf?=
 =?us-ascii?Q?afpakPtf4953Np+XtyhCmFfpJizArMDVBRf/rj2C/hDDOm6D8NvL7jnpjuKY?=
 =?us-ascii?Q?xJrVyWw3rbW/8d3dBcpmhhOFjo6QlIGWy0Y9qwWEVKJcxi4JnXmCsiaAcxxl?=
 =?us-ascii?Q?cgTzfo2mz+Ny8G0o8zrfvInc3aVJa88+Hptf0/ltbsnP06aY7/j3qV0Eioiv?=
 =?us-ascii?Q?lffbTfldR0aZNbQi/shq5Wl+gf7KbF00kEHInQbvPravkM+sd9hqqwopdMk/?=
 =?us-ascii?Q?LYOvmE7IMjA5cKU6+7KhvHelQB61c1mAKW5Bw+50KyzOw7ZubCTYQeUvmvaP?=
 =?us-ascii?Q?asCUuIVfeF0e7KpSmsv1IEn12Na0v9Cl+sGjKA=3D=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SN6PR02MB4157.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: ed590b93-a7c0-4797-c76f-08dc3a21ecd0
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Mar 2024 19:00:56.0826
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY5PR02MB8941

From: Rick Edgecombe <rick.p.edgecombe@intel.com> Sent: Wednesday, February=
 21, 2024 6:10 PM
>=20

See comment in Patch 1 about the "Subject" prefix.

> On TDX it is possible for the untrusted host to cause

See comment in Patch 1 about TDX vs. CoCo VM.

> set_memory_encrypted() or set_memory_decrypted() to fail such that an
> error is returned and the resulting memory is shared. Callers need to tak=
e
> care to handle these errors to avoid returning decrypted (shared) memory =
to
> the page allocator, which could lead to functional or security issues.
>=20
> In order to make sure caller's of vmbus_establish_gpadl() and

s/caller's/callers/

> vmbus_teardown_gpadl() don't return decrypted/shared pages to
> allocators, add a field in struct vmbus_gpadl to keep track of the
> decryption status of the buffer's. This will allow the callers to

s/buffer's/buffers/

> know if they should free or leak the pages.
>=20
> Only compile tested.
>=20
> 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/channel.c   | 11 ++++++++---
>  include/linux/hyperv.h |  1 +
>  2 files changed, 9 insertions(+), 3 deletions(-)
>=20
> diff --git a/drivers/hv/channel.c b/drivers/hv/channel.c
> index 56f7e06c673e..fe5d2f505a39 100644
> --- a/drivers/hv/channel.c
> +++ b/drivers/hv/channel.c
> @@ -478,6 +478,7 @@ static int __vmbus_establish_gpadl(struct
> vmbus_channel *channel,
>  	ret =3D set_memory_decrypted((unsigned long)kbuffer,
>  				   PFN_UP(size));
>  	if (ret) {
> +		gpadl->decrypted =3D false;

There's an earlier error return in this function where
gpadl->decrypted isn't set at all.  I think it works because that
flag is in the channel structure, which is zero'd when allocated,
so the flag defaults to false. But it would probably be better to
explicitly set gpadl->decrypted to false upon entry to the
function so there's no implicit and potentially ambiguous
behavior.

>  		dev_warn(&channel->device_obj->device,
>  			 "Failed to set host visibility for new GPADL %d.\n",
>  			 ret);
> @@ -550,6 +551,7 @@ static int __vmbus_establish_gpadl(struct vmbus_chann=
el *channel,
>  	gpadl->gpadl_handle =3D gpadlmsg->gpadl;
>  	gpadl->buffer =3D kbuffer;
>  	gpadl->size =3D size;
> +	gpadl->decrypted =3D true;

This needs to be done immediately after the call to
set_memory_decrypted() is known to succeed, so that
the "goto cleanup" cases get to the "cleanup:" label
with correct information about the encrypted state
of the memory.

>=20
>=20
>  cleanup:
> @@ -563,9 +565,10 @@ static int __vmbus_establish_gpadl(struct vmbus_chan=
nel *channel,
>=20
>  	kfree(msginfo);
>=20
> -	if (ret)
> -		set_memory_encrypted((unsigned long)kbuffer,
> -				     PFN_UP(size));
> +	if (ret) {
> +		if (set_memory_encrypted((unsigned long)kbuffer, PFN_UP(size)))

Doesn't the above need to be "if (!set_memory_encrypted(...))" ?
Then if set_memory_encrypted() fails, gpadl->decrypted will be "true".

> +			gpadl->decrypted =3D false;
> +	}
>=20
>  	return ret;
>  }
> @@ -886,6 +889,8 @@ int vmbus_teardown_gpadl(struct vmbus_channel
> *channel, struct vmbus_gpadl *gpad
>  	if (ret)
>  		pr_warn("Fail to set mem host visibility in GPADL teardown %d.\n", ret=
);
>=20
> +	gpadl->decrypted =3D ret;
> +
>  	return ret;
>  }
>  EXPORT_SYMBOL_GPL(vmbus_teardown_gpadl);
> diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
> index 2b00faf98017..5bac136c268c 100644
> --- a/include/linux/hyperv.h
> +++ b/include/linux/hyperv.h
> @@ -812,6 +812,7 @@ struct vmbus_gpadl {
>  	u32 gpadl_handle;
>  	u32 size;
>  	void *buffer;
> +	bool decrypted;
>  };
>=20
>  struct vmbus_channel {
> --
> 2.34.1