From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CD5992F7EFD for ; Thu, 25 Jun 2026 17:50:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782409858; cv=none; b=tfhdht6wXwIKDrMNtEcPyHgyjk/tfMKhL/US2tJURxbYb4ExMA5Z9Lqhd6FxLIv3H4smNzJ/bvyaOmeSx0ynyMgDK14TllmZYc0USyqM/jGYDPlgsmCFlWJoRm68D/NVUOjFSnuE9IUHGxOn5bJqYlI+8Wxjy/00UaV2H9EBFTk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782409858; c=relaxed/simple; bh=JskPsisDdF0VFqwJDY/IV1vyX3gklNHe1ipwC/9NiHA=; h=From:Subject:To:Cc:In-Reply-To:References:Content-Type:Date: Message-Id; b=UgufC9mx52eZvUQOIoNb1QfXJZonqXvQJqJWNunJZsEa+xggDy3Mw3UMi0LeCecsZB4wUMrwSZbl5exAlzbW8u3PlkmkhKUMwaeCHXUSEWXSi3gg9L9Qy/BR7cwir7e4RE9bN5ILzEbgGR7f5NIFrteN/hZ4E0m4IAGp27sTCb4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=PL4pr566; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="PL4pr566" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 405101F000E9; Thu, 25 Jun 2026 17:50:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1782409857; bh=3olMyBRRJ5c9LAGC9o7TBKD5FPKftb7Nb386CLXx+cw=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=PL4pr566cPi5Xq/i9LeEd91+LjsWulVqtvIHZXYDLrBhnXzqX00HxKxGT/HYtM5ym Xx4vvunnTkcLICRjaZRD1wPzVhuZfwL1dFHId6QFbPNIAo1XUOrV79LqtroxJGKrK0 +yDOzkvFxo6ef828U3lFjQgTqxqgMBRWsmpGIJKtRua92qVau9Vp2gnhOL/a4m/bNZ 8ZVs6etJF7/2fxpBKUJ0SMLEN3/0ihQUndTtZPqibAMob7T0UbZO1rB2xKjECurd/h ThpOYfnBCZ4KFlHZ1jNS7Z43bWf1e3mvI1K5ox94cE5urr+mIPhsJgBx4CAatNQnYa o7KIt472W4JBA== From: sashiko-bot@kernel.org Subject: Re: [PATCH v2 4/6] Drivers: hv: Mark shared memory as decrypted for CCA Realms Reply-To: sashiko-reviews@lists.linux.dev To: "Kameron Carr" Cc: linux-hyperv@vger.kernel.org In-Reply-To: <20260625173500.1995481-5-kameroncarr@linux.microsoft.com> References: <20260625173500.1995481-1-kameroncarr@linux.microsoft.com> <20260625173500.1995481-5-kameroncarr@linux.microsoft.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Thu, 25 Jun 2026 17:50:56 +0000 Message-Id: <20260625175057.405101F000E9@smtp.kernel.org> Precedence: bulk X-Mailing-List: linux-hyperv@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Thank you for your contribution! Sashiko AI review found 1 potential issue(= s) to consider: Pre-existing issues: - [High] Using `kmalloc()` to allocate hypercall input/output pages violate= s the strict page-alignment requirements of `set_memory_decrypted()`, causi= ng silent failures on ARM64 and exposing slab metadata to the untrusted hos= t on x86. -- commit 02dd1b4271844f489855c82e06efdec7e95897e3 Author: Kameron Carr Drivers: hv: Mark shared memory as decrypted for CCA Realms This commit extends the confidential VM shared memory decryption handling for hypercall input/output pages to support Arm CCA Realm guests. It also updates the memory allocation to round up to the nearest page size to satis= fy decryption requirements. > diff --git a/drivers/hv/hv_common.c b/drivers/hv/hv_common.c > index 6b67ac6167891..17048a0a18729 100644 > --- a/drivers/hv/hv_common.c > +++ b/drivers/hv/hv_common.c [ ... ] > @@ -489,7 +490,7 @@ int hv_common_cpu_init(unsigned int cpu) > * online and then taken offline > */ > if (!*inputarg) { > - mem =3D kmalloc_array(pgcount, HV_HYP_PAGE_SIZE, flags); > + mem =3D kmalloc(alloc_size, flags); > if (!mem) > return -ENOMEM; > =20 > @@ -499,14 +500,16 @@ int hv_common_cpu_init(unsigned int cpu) > } > =20 > if (!ms_hyperv.paravisor_present && > - (hv_isolation_type_snp() || hv_isolation_type_tdx())) { > - ret =3D set_memory_decrypted((unsigned long)mem, pgcount); > + (hv_isolation_type_snp() || hv_isolation_type_tdx() || > + hv_isolation_type_cca())) { > + ret =3D set_memory_decrypted((unsigned long)kasan_reset_tag(mem), > + alloc_size >> PAGE_SHIFT); [Severity: High] This is a pre-existing issue, but does using kmalloc() here guarantee the required page alignment for set_memory_decrypted()? When slub debugging (like redzoning) is enabled, kmalloc() can return an unaligned address due to prepended metadata. On arm64, set_memory_decrypted() requires a page-aligned address. If given an unaligned address, it warns and returns 0 without decrypting. This leaves the hypercall pages encrypted, which breaks guest-hypervisor communication for CCA Realms. On x86, set_memory_decrypted() masks the address to the page boundary. Because this memory is from a slab cache, decrypting the entire underlying physical page could expose other unrelated kernel slab objects on the same page to the untrusted hypervisor. > if (ret) { > /* It may be unsafe to free 'mem' */ > return ret; > } > =20 > - memset(mem, 0x00, pgcount * HV_HYP_PAGE_SIZE); > + memset(mem, 0x00, alloc_size); > } --=20 Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260625173500.1995= 481-1-kameroncarr@linux.microsoft.com?part=3D4