From: Aneesh Kumar K.V <aneesh.kumar@kernel.org>
To: "Jason Gunthorpe" <jgg@ziepe.ca>,
"Christian König" <christian.koenig@amd.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
linux-coco@lists.linux.dev, kvmarm@lists.linux.dev,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, iommu@lists.linux.dev,
Marc Zyngier <maz@kernel.org>,
Marek Szyprowski <m.szyprowski@samsung.com>,
Robin Murphy <robin.murphy@arm.com>,
Steven Price <steven.price@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Thomas Gleixner <tglx@kernel.org>, Will Deacon <will@kernel.org>,
Sumit Semwal <sumit.semwal@linaro.org>,
"T.J. Mercier" <tjmercier@google.com>
Subject: Re: [PATCH v6 7/9] dma-buf: system_heap: Enforce shared-granule alignment for cc-shared buffers
Date: Sat, 19 Sep 2026 20:27:29 +0530 [thread overview]
Message-ID: <yq5atsnl47c6.fsf@kernel.org> (raw)
In-Reply-To: <20260918153642.GD11599@ziepe.ca>
Jason Gunthorpe <jgg@ziepe.ca> writes:
> On Fri, Sep 18, 2026 at 05:23:32PM +0200, Christian König wrote:
>> On 9/18/26 17:16, Catalin Marinas wrote:
>> > First, none of the DMA-BUF maintainers have been cc'ed. It might be fine
>> > for an RFC but this series got to version 6. We need their feedback.
>>
>> Yeah, thanks for doing this.
>> > On Fri, Sep 04, 2026 at 04:04:50PM +0530, Aneesh Kumar K.V (Arm) wrote:
>> >> The system heap can allocate buffers that are decrypted and shared with the
>> >> host. For confidential-computing guests, those shared buffers must cover
>> >> whole shared-buffer granule; otherwise a userspace mmap of the dma-buf may
>> >> expose only part of a host-managed granule and allow unintended access to
>> >> adjacent private memory.
>> >>
>> >> Require cc-shared system-heap allocations to have a size aligned to
>> >> mem_cc_shared_granule_size(), and allocate pages at least as large as the
>> >> required granule. Keep the allocation bounded by the existing heap orders,
>> >> but fall back to an exact minimum-order allocation when the required
>> >> granule is not one of the preferred heap orders.
>>
>> Uff, I don't think we can do that.
>>
>> That is massively platform specific behavior in a non platform
>> specific code.
>
> What we really need is an allocator API that does all this for the caller.
>
> It has been pointed out a few times, Aneesh maybe you need to try to
> tackle that?
>
> dmabuf heap just wants
>
> 'allocate me an array of shared folios totaling XX bytes'
>
> Arch code can figure out how to do it. If some ARM configs only give
> order 4 folios or whatever then dmabuf heap doesn't care.
>
> And solve the double/triple zeroing problem.
>
Agreed. Moving all the CoCo shared-allocation rules into one place makes
this easier to follow.
+static struct page *system_heap_alloc_order(unsigned int order, gfp_t flags,
+ bool cc_shared)
+{
+ struct cc_shared_pages mem;
+
+ if (!cc_shared)
+ return alloc_pages(flags, order);
+
+ /* The shared granule can raise the actual allocation order. */
+ flags |= __GFP_COMP;
+ if (alloc_cc_shared_pages(flags, PAGE_SIZE << order, &mem))
+ return NULL;
+
+ return mem.page;
+}
+
static struct page *alloc_largest_available(unsigned long size,
- unsigned int max_order)
+ unsigned int max_order,
+ bool cc_shared)
{
struct page *page;
int i;
gfp_t flags;
for (i = 0; i < NUM_ORDERS; i++) {
if (size < (PAGE_SIZE << orders[i]))
continue;
if (max_order < orders[i])
continue;
flags = order_flags[i];
if (mem_accounting)
flags |= __GFP_ACCOUNT;
- page = alloc_pages(flags, orders[i]);
+ page = system_heap_alloc_order(orders[i], flags, cc_shared);
if (!page)
continue;
return page;
with mm/cc_shared.c having
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);
mem->page = page;
mem->shared_size = layout.shared_size;
return 0;
}
-aneesh
next prev parent reply other threads:[~2026-09-19 14:57 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-04 10:34 [PATCH v6 0/9] coco: guest: Enforce host page-size alignment for shared buffers Aneesh Kumar K.V (Arm)
2026-09-04 10:34 ` [PATCH v6 1/9] mm/mem_encrypt: Add helpers for shared-buffer alignment Aneesh Kumar K.V (Arm)
2026-09-04 10:34 ` [PATCH v6 2/9] irqchip/gic-v3-its: Align shared ITS allocations to the CoCo shared granule size Aneesh Kumar K.V (Arm)
2026-09-04 10:34 ` [PATCH v6 3/9] dma-mapping: Pass allocation attrs to contiguous allocation helpers Aneesh Kumar K.V (Arm)
2026-09-04 10:34 ` [PATCH v6 4/9] dma-direct: Align CoCo shared DMA allocations to the shared granule size Aneesh Kumar K.V (Arm)
2026-09-18 14:16 ` Catalin Marinas
2026-09-04 10:34 ` [PATCH v6 5/9] swiotlb: Align shared IO TLB pools " Aneesh Kumar K.V (Arm)
2026-09-04 10:34 ` [PATCH v6 6/9] swiotlb: Reject misaligned restricted DMA pools for CoCo guests Aneesh Kumar K.V (Arm)
2026-09-04 10:34 ` [PATCH v6 7/9] dma-buf: system_heap: Enforce shared-granule alignment for cc-shared buffers Aneesh Kumar K.V (Arm)
2026-09-18 15:16 ` Catalin Marinas
2026-09-18 15:23 ` Christian König
2026-09-18 15:36 ` Jason Gunthorpe
2026-09-18 15:39 ` Christian König
2026-09-18 16:53 ` Jason Gunthorpe
2026-09-21 9:07 ` Christian König
2026-09-21 11:51 ` Jason Gunthorpe
2026-09-21 12:05 ` Christian König
2026-09-21 12:17 ` Jason Gunthorpe
2026-09-21 12:24 ` Christian König
2026-09-21 12:37 ` Jason Gunthorpe
2026-09-21 15:26 ` Aneesh Kumar K.V
2026-09-22 15:38 ` Catalin Marinas
2026-09-23 5:05 ` Aneesh Kumar K.V
2026-09-19 14:57 ` Aneesh Kumar K.V [this message]
2026-09-19 21:35 ` Jason Gunthorpe
2026-09-20 7:24 ` Aneesh Kumar K.V
2026-09-21 6:57 ` Aneesh Kumar K.V
2026-09-04 10:34 ` [PATCH v6 8/9] arm64: realm: Add RHI helper to query IPA state change alignment Aneesh Kumar K.V (Arm)
2026-09-16 16:12 ` Suzuki K Poulose
2026-09-18 10:39 ` Aneesh Kumar K.V
2026-09-04 10:34 ` [PATCH v6 9/9] arm64: realm: Expose the CCA shared granule size through mem_encrypt ops Aneesh Kumar K.V (Arm)
2026-09-16 16:17 ` Suzuki K Poulose
2026-09-18 16:52 ` [PATCH v6 0/9] coco: guest: Enforce host page-size alignment for shared buffers Catalin Marinas
2026-09-18 16:57 ` Jason Gunthorpe
2026-09-18 17:10 ` Catalin Marinas
2026-09-23 5:01 ` Aneesh Kumar K.V
2026-09-23 15:58 ` Jason Gunthorpe
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=yq5atsnl47c6.fsf@kernel.org \
--to=aneesh.kumar@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=christian.koenig@amd.com \
--cc=iommu@lists.linux.dev \
--cc=jgg@ziepe.ca \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-coco@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=maz@kernel.org \
--cc=robin.murphy@arm.com \
--cc=steven.price@arm.com \
--cc=sumit.semwal@linaro.org \
--cc=suzuki.poulose@arm.com \
--cc=tglx@kernel.org \
--cc=tjmercier@google.com \
--cc=will@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.