[RFC PATCH v7 02/13] mm: Add an allocator for CoCo shared memory
Aneesh Kumar K.V
aneesh.kumar at kernel.org
Wed Sep 23 01:31:08 PDT 2026
Aneesh Kumar K.V <aneesh.kumar at kernel.org> writes:
> Catalin Marinas <catalin.marinas at arm.com> writes:
>
>> On Mon, Sep 21, 2026 at 08:18:36PM +0530, Aneesh Kumar K.V (Arm) wrote:
>>> +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.
>
> Also, if zeroing is added only to the CCA implementation, the allocator
> must retain __GFP_ZERO for platforms such as pKVM. This would cause the
> memory to be zeroed twice on CCA.
>
> How about extending cc_make_shared() with a flag indicating that the
> memory must be zeroed, and passing that requirement down to the
> architecture-specific implementation? The implementation could then zero
> the memory at the appropriate point: before sharing for pKVM and after
> the destructive transition for CCA.
>
> The allocator could derive this flag from __GFP_ZERO, remove __GFP_ZERO
> before calling alloc_pages(), and let the sharing operation perform the
> requested zeroing with the correct ordering.
>
I was pointed to this email thread:
https://lore.kernel.org/all/c25502d3-35c6-4281-a9ec-856f789fb1b4@arm.com
This makes a stronger case for having a CoCo shared memory allocator
that captures all these restrictions. It also means that
alloc_cc_shared_pages_node() needs:
if (WARN_ON_ONCE(!gfpflags_allow_blocking(gfp)))
return -EINVAL;
might_sleep();
I guess this also requires the VPE L1 tables to be preallocated from a sleepable context.
-aneesh
More information about the linux-arm-kernel
mailing list