Catalin Marinas [off-list ref] writes:
On Wed, Sep 23, 2026 at 11:23:27AM +0530, Aneesh Kumar K.V wrote:
quoted
Catalin Marinas [off-list ref] writes:
quoted
On Mon, Sep 21, 2026 at 08:18:36PM +0530, Aneesh Kumar K.V (Arm) wrote:
quoted
+int alloc_cc_shared_pages_node(int nid, gfp_t gfp,
+ size_t requested, struct cc_shared_pages *mem)
+{
+ struct cc_shared_layout layout;
+ struct page *page;
+ unsigned int order;
+ bool zero = gfp & __GFP_ZERO;
+ int ret;
+
+ if (!mem)
+ return -EINVAL;
+
+ ret = cc_shared_calc_layout(requested, &layout);
+ if (ret)
+ return ret;
+
+ order = get_order(layout.shared_size);
+ if (order > MAX_PAGE_ORDER)
+ return -EINVAL;
+
+ /*
+ * State transitions require a linear-map address and may modify memory.
+ * Allocate from low memory and defer requested zeroing until afterwards.
+ */
+ gfp &= ~(__GFP_HIGHMEM | __GFP_ZERO);
+ if (nid == NUMA_NO_NODE)
+ page = alloc_pages(gfp, order);
+ else
+ page = alloc_pages_node(nid, gfp, order);
+ if (!page)
+ return -ENOMEM;
+
+ ret = cc_make_shared(page_address(page), layout.shared_size);
+ if (ret) {
+ if (!cc_make_private(page_address(page), layout.shared_size))
+ __free_pages(page, order);
+ else
+ pr_warn_ratelimited("leaking %zu bytes with uncertain shared state\n",
+ layout.shared_size);
+ return ret;
+ }
+
+ if (zero)
+ memset(page_address(page), 0, layout.shared_size);
Does the memset() post sharing logic work for pKVM as well? If nothing
clears it, we have a small window where guest data is leaked to the
host.
Is there a case where we *do not* need the memory cleared? If not, maybe
we can move the logic in the arch set_memory_decrypted().
I don't think every architecture or platform can unconditionally zero
memory in set_memory_decrypted(). Some callers may need to share valid
contents with the host.
Is there any? That would be a bad assumptions in the caller. Most
set_memory_* backends don't preserve the content as they change the
encryption key. So properly written code shouldn't rely on this unless
it knows specifically it's only running on pKVM for example. The only
use-case I see to avoid explicit zeroing is when the caller doesn't care
about the page initialisation and wants to save some cycles. The
encryption key change would take care of the security aspect.
I checked this, and you are right. We cannot expect the contents to
remain valid across sharing; set_memory_decrypted() is destructive in
that sense. Since pKVM does not rely on memory encryption, it needs to
zero the memory unconditionally in set_memory_decrypted() to avoid
exposing existing guest data. Other CoCo implementations may omit the
memset(0). We still need to zero the memory when the caller requests
__GFP_ZERO, where the memory location is expected to be zero.
We could either zero the memory unconditionally or pass a flag to allow
this micro-optimization. We would also need to audit all call paths to
avoid redundant zeroing after set_memory_decrypted(). Let me know if you
have a preference for either approach.
-aneesh