Aneesh Kumar K.V <[email protected]> writes:

> Catalin Marinas <[email protected]> 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/[email protected]

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


Reply via email to