From: Aneesh Kumar K.V <aneesh.kumar@kernel.org>
To: sashiko-reviews@lists.linux.dev
Cc: "Andrew Morton" <akpm@linux-foundation.org>,
"Baoquan He" <baoquan.he@linux.dev>,
"Mike Rapoport" <rppt@kernel.org>,
"Pasha Tatashin" <pasha.tatashin@soleen.com>,
"Pratyush Yadav" <pratyush@kernel.org>,
"Catalin Marinas" <catalin.marinas@arm.com>,
"Christian König" <christian.koenig@amd.com>,
"Jason Gunthorpe" <jgg@ziepe.ca>,
"Joerg Roedel" <joro@8bytes.org>, "Marc Zyngier" <maz@kernel.org>,
"Marek Szyprowski" <m.szyprowski@samsung.com>,
"Robin Murphy" <robin.murphy@arm.com>,
"Steven Price" <steven.price@arm.com>,
"Sumit Semwal" <sumit.semwal@linaro.org>,
"Suzuki K Poulose" <suzuki.poulose@arm.com>,
"Thomas Gleixner" <tglx@kernel.org>,
"Will Deacon" <will@kernel.org>,
"Russell King" <linux@armlinux.org.uk>,
"Benjamin Gaignard" <benjamin.gaignard@collabora.com>,
"Brian Starkey" <Brian.Starkey@arm.com>,
"John Stultz" <jstultz@google.com>,
"Mark Rutland" <mark.rutland@arm.com>,
"Radu Rendec" <radu@rendec.net>,
"T.J. Mercier" <tjmercier@google.com>,
"Madhavan Srinivasan" <maddy@linux.ibm.com>,
"Michael Ellerman" <mpe@ellerman.id.au>,
"Nicholas Piggin" <npiggin@gmail.com>,
"Christophe Leroy" <chleroy@kernel.org>,
"Ritesh Harjani" <ritesh.list@gmail.com>,
"Shrikanth Hegde" <sshegde@linux.ibm.com>,
"Alexander Gordeev" <agordeev@linux.ibm.com>,
"Gerald Schaefer" <gerald.schaefer@linux.ibm.com>,
"Heiko Carstens" <hca@linux.ibm.com>,
"Vasily Gorbik" <gor@linux.ibm.com>,
"Christian Borntraeger" <borntraeger@linux.ibm.com>,
"Sven Schnelle" <svens@linux.ibm.com>,
"Ingo Molnar" <mingo@redhat.com>,
"Borislav Petkov" <bp@alien8.de>,
"Dave Hansen" <dave.hansen@linux.intel.com>,
x86@kernel.org, "H . Peter Anvin" <hpa@zytor.com>,
"Kiryl Shutsemau" <kas@kernel.org>,
"Rick Edgecombe" <rick.p.edgecombe@intel.com>,
"K . Y . Srinivasan" <kys@microsoft.com>,
"Haiyang Zhang" <haiyangz@microsoft.com>,
"Wei Liu" <wei.liu@kernel.org>,
"Dexuan Cui" <decui@microsoft.com>,
"Long Li" <longli@microsoft.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Vitaly Kuznetsov" <vkuznets@redhat.com>,
"Andy Lutomirski" <luto@kernel.org>,
"Peter Zijlstra" <peterz@infradead.org>,
dri-devel@lists.freedesktop.org, linux-mm@kvack.org,
kvmarm@lists.linux.dev, "Oliver Upton" <oupton@kernel.org>,
media-ci@linuxtv.org
Subject: Re: [PATCH v9 02/14] mm: Zero memory during shared memory transitions
Date: Thu, 12 Nov 2026 22:59:05 +0530 [thread overview]
Message-ID: <yq5av762gdr2.fsf@kernel.org> (raw)
In-Reply-To: <sashiko-outbox-199540@kernel.org>
sashiko-bot@kernel.org writes:
> Thank you for your contribution! Sashiko AI review found 5 potential issue(s) to consider:
> - [Critical] x86/hyperv: premature zeroing in hv_vtom_clear_present() before transition
> - [High] Drivers: hv: uninitialized SynIC pages in hv_alloc_page() on non-CoCo VMs
> - [High] dma-pool: dirty cache lines left on linear alias by set_memory_decrypted()
> - [Medium] x86/mm: set_memory_decrypted() zeroes legacy VGA VRAM/MMIO in VGA_MAP_MEM()
> - [Medium] powerpc/pseries/svm: set_memory_decrypted() zeroes private page before sharing
> --
>
I used an LLM to review the CoCo implementations and suggest the correct
sequence for clearing memory. Except on s390 and pKVM, memory must be
cleared after it is converted to shared. The resulting patch is below,
with comments explaining the architecture-specific differences.
This needs review and acknowledgment from the relevant architecture
maintainers.
modified arch/arm64/mm/mem_encrypt.c
@@ -17,6 +17,7 @@
#include <linux/compiler.h>
#include <linux/err.h>
#include <linux/mm.h>
+#include <linux/string.h>
#include <asm/mem_encrypt.h>
@@ -42,8 +43,13 @@ EXPORT_SYMBOL_GPL(set_memory_encrypted);
int set_memory_decrypted(unsigned long addr, int numpages)
{
- if (likely(!crypt_ops) || WARN_ON(!PAGE_ALIGNED(addr)))
+ if (likely(!crypt_ops)) {
+ memset((void *)addr, 0, (size_t)numpages << PAGE_SHIFT);
return 0;
+ }
+
+ if (WARN_ON(!PAGE_ALIGNED(addr)))
+ return -EINVAL;
return crypt_ops->decrypt(addr, numpages);
}
modified arch/powerpc/platforms/pseries/svm.c
@@ -54,14 +54,13 @@ int set_memory_encrypted(unsigned long addr, int numpages)
int set_memory_decrypted(unsigned long addr, int numpages)
{
- if (!cc_platform_has(CC_ATTR_MEM_ENCRYPT))
- return 0;
-
if (!PAGE_ALIGNED(addr))
return -EINVAL;
+ if (cc_platform_has(CC_ATTR_MEM_ENCRYPT))
+ uv_share_page(PHYS_PFN(__pa(addr)), numpages);
+ /* Sharing can replace the secure backing; clear the final mapping. */
memset((void *)addr, 0, (size_t)numpages << PAGE_SHIFT);
- uv_share_page(PHYS_PFN(__pa(addr)), numpages);
return 0;
}
modified arch/s390/mm/init.c
@@ -130,6 +130,10 @@ int set_memory_decrypted(unsigned long vaddr, int numpages)
{
int i;
+ /*
+ * uv_set_shared() exposes existing contents to the host; see the data
+ * leakage warning in share() in asm/uv.h. Clear private data first.
+ */
memset((void *)vaddr, 0, (size_t)numpages << PAGE_SHIFT);
/* make specified pages shared (swiotlb, dma_alloca) */
modified arch/x86/coco/tdx/tdx.c
@@ -980,9 +980,6 @@ static int tdx_enc_status_change_finish(unsigned long vaddr, int numpages,
if (!enc && !tdx_enc_status_changed(vaddr, numpages, enc))
return -EIO;
- if (!enc)
- memset((void *)vaddr, 0, (size_t)numpages << PAGE_SHIFT);
-
if (enc)
atomic_long_sub(numpages, &nr_shared);
else
modified arch/x86/hyperv/ivm.c
@@ -755,10 +755,6 @@ static int hv_mark_gpa_visibility(u16 count, const u64 pfn[],
*/
static int hv_vtom_clear_present(unsigned long kbuffer, int pagecount, bool enc)
{
- if (!enc)
- memset((void *)kbuffer, 0,
- (size_t)pagecount << PAGE_SHIFT);
-
return set_memory_np(kbuffer, pagecount);
}
modified arch/x86/include/asm/set_memory.h
@@ -52,6 +52,7 @@ bool set_memory_enc_stop_conversion(void);
bool set_memory_enc_stop_conversion(void);
int set_memory_encrypted(unsigned long addr, int numpages);
int set_memory_decrypted(unsigned long addr, int numpages);
+int set_memory_decrypted_nozero(unsigned long addr, int numpages);
int set_memory_np_noalias(unsigned long addr, int numpages);
int set_memory_nonglobal(unsigned long addr, int numpages);
modified arch/x86/include/asm/vga.h
@@ -14,7 +14,7 @@
* On the PC, we can just recalculate addresses and then
* access the videoram directly without any black magic.
* To support memory encryption however, we need to access
- * the videoram as decrypted memory.
+ * the videoram as decrypted memory without clearing its contents.
*/
#define VGA_MAP_MEM(x, s) \
@@ -22,7 +22,7 @@
unsigned long start = (unsigned long)phys_to_virt(x); \
\
if (IS_ENABLED(CONFIG_AMD_MEM_ENCRYPT)) \
- set_memory_decrypted(start, (s) >> PAGE_SHIFT); \
+ set_memory_decrypted_nozero(start, (s) >> PAGE_SHIFT); \
\
start; \
})
modified arch/x86/mm/mem_encrypt_amd.c
@@ -309,9 +309,6 @@ static int amd_enc_status_change_finish(unsigned long vaddr, int npages, bool en
if (!cc_platform_has(CC_ATTR_HOST_MEM_ENCRYPT))
enc_dec_hypercall(vaddr, npages << PAGE_SHIFT, enc);
- if (!enc)
- memset((void *)vaddr, 0, (size_t)npages << PAGE_SHIFT);
-
return 0;
}
modified arch/x86/mm/pat/set_memory.c
@@ -2545,9 +2545,22 @@ EXPORT_SYMBOL_GPL(set_memory_encrypted);
int set_memory_decrypted(unsigned long addr, int numpages)
{
+ int ret = __set_memory_enc_dec(addr, numpages, false);
+
+ /* The finish callback must restore the shared mapping before clearing. */
+ if (!ret)
+ memset((void *)addr, 0, (size_t)numpages << PAGE_SHIFT);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(set_memory_decrypted);
+
+/* Device memory needs a decrypted mapping without writes to its contents. */
+int set_memory_decrypted_nozero(unsigned long addr, int numpages)
+{
return __set_memory_enc_dec(addr, numpages, false);
}
-EXPORT_SYMBOL_GPL(set_memory_decrypted);
+EXPORT_SYMBOL_GPL(set_memory_decrypted_nozero);
int set_pages_uc(struct page *page, int numpages)
{
modified drivers/firmware/arm_rmm/rsi.c
@@ -147,6 +147,7 @@ static int realm_set_memory_decrypted(unsigned long addr, int numpages)
{
int ret = __set_memory_enc_dec(addr, numpages, false);
+ /* The transition invalidates private contents; clear the shared mapping. */
if (!ret)
memset((void *)addr, 0, (size_t)numpages << PAGE_SHIFT);
modified drivers/virt/coco/pkvm-guest/arm-pkvm-guest.c
@@ -62,6 +62,7 @@ static int pkvm_set_memory_encrypted(unsigned long addr, int numpages)
static int pkvm_set_memory_decrypted(unsigned long addr, int numpages)
{
+ /* Sharing exposes the existing contents to the host; clear them first. */
memset((void *)addr, 0, (size_t)numpages << PAGE_SHIFT);
return __set_memory_range(ARM_SMCCC_VENDOR_HYP_KVM_MEM_SHARE_FUNC_ID,
modified include/linux/set_memory.h
@@ -5,6 +5,10 @@
#ifndef _LINUX_SET_MEMORY_H_
#define _LINUX_SET_MEMORY_H_
+#include <linux/string.h>
+
+#include <asm/page.h>
+
/**
* DOC: Kernel page table permissions
*
@@ -21,7 +25,8 @@
*
* When an architecture does not implement these APIs they succeed without
* doing anything, so a return value of 0 does not mean that the permissions
- * were actually changed.
+ * were actually changed. set_memory_decrypted() also clears the range,
+ * including when no encryption change is needed. It is for normal RAM only.
*
* Callers that depend on the permissions being applied must ensure that the
* architecture supports the required operation for the target addresses. The
@@ -186,6 +191,7 @@ static inline int set_memory_encrypted(unsigned long addr, int numpages)
static inline int set_memory_decrypted(unsigned long addr, int numpages)
{
+ memset((void *)addr, 0, (size_t)numpages << PAGE_SHIFT);
return 0;
}
#endif /* CONFIG_ARCH_HAS_MEM_ENCRYPT */
next prev parent reply other threads:[~2026-11-12 17:29 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-04 16:45 [PATCH v9 00/14] coco: guest: Add a shared-granule allocator for host-shared memory Aneesh Kumar K.V (Arm)
2026-11-04 16:45 ` [PATCH v9 01/14] mm: Add an allocator for CoCo shared memory Aneesh Kumar K.V (Arm)
2026-11-05 16:52 ` sashiko-bot
2026-11-12 16:49 ` Aneesh Kumar K.V
2026-11-06 14:41 ` Suzuki K Poulose
2026-11-06 15:30 ` Aneesh Kumar K.V
2026-11-06 15:34 ` Suzuki K Poulose
2026-11-04 16:45 ` [PATCH v9 02/14] mm: Zero memory during shared memory transitions Aneesh Kumar K.V (Arm)
2026-11-05 16:52 ` sashiko-bot
2026-11-12 17:29 ` Aneesh Kumar K.V [this message]
2026-11-04 16:45 ` [PATCH v9 03/14] irqchip/gic-v3-its: Resolve the default NUMA node explicitly Aneesh Kumar K.V (Arm)
2026-11-04 16:45 ` [PATCH v9 04/14] irqchip/gic-v3-its: Allocate shared tables using CoCo shared memory allocator Aneesh Kumar K.V (Arm)
2026-11-04 16:45 ` [PATCH v9 05/14] dma-contiguous: Derive shared alignment from DMA attributes Aneesh Kumar K.V (Arm)
2026-11-04 16:45 ` [PATCH v9 06/14] dma-pool: Allocate CoCo atomic pools using CoCo shared memory allocator Aneesh Kumar K.V (Arm)
2026-11-05 16:52 ` sashiko-bot
2026-11-04 16:45 ` [PATCH v9 07/14] dma-direct: Align CoCo shared DMA allocations to the shared granule size Aneesh Kumar K.V (Arm)
2026-11-04 16:45 ` [PATCH v9 08/14] swiotlb: Align shared IO TLB pools " Aneesh Kumar K.V (Arm)
2026-11-05 16:52 ` sashiko-bot
2026-11-04 16:45 ` [PATCH v9 09/14] swiotlb: Reject misaligned restricted DMA pools for CoCo guests Aneesh Kumar K.V (Arm)
2026-11-04 16:45 ` [PATCH v9 10/14] dma-buf: system_heap: Limit scatterlist entries to the buffer size Aneesh Kumar K.V (Arm)
2026-11-04 16:45 ` [PATCH v9 11/14] dma-buf: system_heap: Allocate shared buffers using CoCo shared memory allocator Aneesh Kumar K.V (Arm)
2026-11-04 16:45 ` [PATCH v9 12/14] swiotlb: Make rounded shared pool capacity allocatable Aneesh Kumar K.V (Arm)
2026-11-04 16:45 ` [PATCH v9 13/14] mm: Assert CoCo shared allocations may sleep Aneesh Kumar K.V (Arm)
2026-11-04 16:45 ` [PATCH v9 14/14] irqchip/gic-v3-its: Preallocate VPE L1 tables Aneesh Kumar K.V (Arm)
2026-11-05 16:20 ` Marc Zyngier
2026-11-06 15:45 ` Aneesh Kumar K.V
2026-11-05 16:52 ` sashiko-bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=yq5av762gdr2.fsf@kernel.org \
--to=aneesh.kumar@kernel.org \
--cc=Brian.Starkey@arm.com \
--cc=agordeev@linux.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=baoquan.he@linux.dev \
--cc=benjamin.gaignard@collabora.com \
--cc=borntraeger@linux.ibm.com \
--cc=bp@alien8.de \
--cc=catalin.marinas@arm.com \
--cc=chleroy@kernel.org \
--cc=christian.koenig@amd.com \
--cc=dave.hansen@linux.intel.com \
--cc=decui@microsoft.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=gerald.schaefer@linux.ibm.com \
--cc=gor@linux.ibm.com \
--cc=haiyangz@microsoft.com \
--cc=hca@linux.ibm.com \
--cc=hpa@zytor.com \
--cc=jgg@ziepe.ca \
--cc=joro@8bytes.org \
--cc=jstultz@google.com \
--cc=kas@kernel.org \
--cc=kvmarm@lists.linux.dev \
--cc=kys@microsoft.com \
--cc=linux-mm@kvack.org \
--cc=linux@armlinux.org.uk \
--cc=longli@microsoft.com \
--cc=luto@kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=maddy@linux.ibm.com \
--cc=mark.rutland@arm.com \
--cc=maz@kernel.org \
--cc=media-ci@linuxtv.org \
--cc=mingo@redhat.com \
--cc=mpe@ellerman.id.au \
--cc=npiggin@gmail.com \
--cc=oupton@kernel.org \
--cc=pasha.tatashin@soleen.com \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=pratyush@kernel.org \
--cc=radu@rendec.net \
--cc=rick.p.edgecombe@intel.com \
--cc=ritesh.list@gmail.com \
--cc=robin.murphy@arm.com \
--cc=rppt@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=sshegde@linux.ibm.com \
--cc=steven.price@arm.com \
--cc=sumit.semwal@linaro.org \
--cc=suzuki.poulose@arm.com \
--cc=svens@linux.ibm.com \
--cc=tglx@kernel.org \
--cc=tjmercier@google.com \
--cc=vkuznets@redhat.com \
--cc=wei.liu@kernel.org \
--cc=will@kernel.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox