From: "Aneesh Kumar K.V (Arm)" <aneesh.kumar@kernel.org>
To: linux-coco@lists.linux.dev, kvmarm@lists.linux.dev,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, iommu@lists.linux.dev
Cc: "Aneesh Kumar K.V (Arm)" <aneesh.kumar@kernel.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Jason Gunthorpe <jgg@ziepe.ca>, 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>
Subject: [PATCH v5 07/10] dma-buf: system_heap: Enforce shared-granule alignment for cc-shared buffers
Date: Mon, 6 Jul 2026 11:34:29 +0530 [thread overview]
Message-ID: <20260706060432.1375570-8-aneesh.kumar@kernel.org> (raw)
In-Reply-To: <20260706060432.1375570-1-aneesh.kumar@kernel.org>
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.
Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org>
---
drivers/dma-buf/heaps/system_heap.c | 50 +++++++++++++++++++++++------
1 file changed, 41 insertions(+), 9 deletions(-)
diff --git a/drivers/dma-buf/heaps/system_heap.c b/drivers/dma-buf/heaps/system_heap.c
index c8959eadc71d..9cbfcebe2088 100644
--- a/drivers/dma-buf/heaps/system_heap.c
+++ b/drivers/dma-buf/heaps/system_heap.c
@@ -55,7 +55,6 @@ struct dma_heap_attachment {
#define HIGH_ORDER_GFP (((GFP_HIGHUSER | __GFP_ZERO | __GFP_NOWARN \
| __GFP_NORETRY) & ~__GFP_RECLAIM) \
| __GFP_COMP)
-static gfp_t order_flags[] = {HIGH_ORDER_GFP, HIGH_ORDER_GFP, LOW_ORDER_GFP};
/*
* The selection of the orders used for allocation (1MB, 64K, 4K) is designed
* to match with the sizes often found in IOMMUs. Using order 4 pages instead
@@ -375,26 +374,44 @@ static const struct dma_buf_ops system_heap_buf_ops = {
.release = system_heap_dma_buf_release,
};
+static struct page *system_heap_alloc_order(unsigned int order)
+{
+ gfp_t flags = order ? HIGH_ORDER_GFP : LOW_ORDER_GFP;
+
+ if (mem_accounting)
+ flags |= __GFP_ACCOUNT;
+
+ return alloc_pages(flags, order);
+}
+
static struct page *alloc_largest_available(unsigned long size,
- unsigned int max_order)
+ unsigned int max_order,
+ unsigned int min_order)
{
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])
+
+ if (max_order < orders[i] || orders[i] < min_order)
continue;
- flags = order_flags[i];
- if (mem_accounting)
- flags |= __GFP_ACCOUNT;
- page = alloc_pages(flags, orders[i]);
+
+ page = system_heap_alloc_order(orders[i]);
if (!page)
continue;
return page;
}
+ /*
+ * The required minimum order might not be one of the preferred heap
+ * orders. Allocate exactly min_order when it does not exceed the
+ * remaining size.
+ */
+ if (min_order && min_order <= max_order &&
+ size >= (PAGE_SIZE << min_order))
+ return system_heap_alloc_order(min_order);
+
return NULL;
}
@@ -409,6 +426,8 @@ static struct dma_buf *system_heap_allocate(struct dma_heap *heap,
unsigned int max_order = orders[0];
struct system_heap_priv *priv = dma_heap_get_drvdata(heap);
bool cc_shared = priv->cc_shared;
+ unsigned int min_order = 0;
+ size_t cc_granule_size;
struct dma_buf *dmabuf;
struct sg_table *table;
struct scatterlist *sg;
@@ -425,6 +444,18 @@ static struct dma_buf *system_heap_allocate(struct dma_heap *heap,
buffer->heap = heap;
buffer->len = len;
buffer->cc_shared = cc_shared;
+ if (cc_shared_buffer(buffer)) {
+ cc_granule_size = mem_cc_shared_granule_size();
+ if (!IS_ALIGNED(len, cc_granule_size)) {
+ ret = -EINVAL;
+ goto free_buffer;
+ }
+ min_order = get_order(cc_granule_size);
+ if (min_order > max_order) {
+ ret = -EINVAL;
+ goto free_buffer;
+ }
+ }
INIT_LIST_HEAD(&pages);
i = 0;
@@ -438,7 +469,8 @@ static struct dma_buf *system_heap_allocate(struct dma_heap *heap,
goto free_buffer;
}
- page = alloc_largest_available(size_remaining, max_order);
+ page = alloc_largest_available(size_remaining, max_order,
+ min_order);
if (!page)
goto free_buffer;
--
2.43.0
next prev parent reply other threads:[~2026-07-06 6:05 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-06 6:04 [PATCH v5 00/10] coco: guest: Enforce host page-size alignment for shared buffers Aneesh Kumar K.V (Arm)
2026-07-06 6:04 ` [PATCH v5 01/10] mm/mem_encrypt: Add helpers for shared-buffer alignment Aneesh Kumar K.V (Arm)
2026-07-06 6:04 ` [PATCH v5 02/10] irqchip/gic-v3-its: Align shared ITS allocations to the CoCo shared granule size Aneesh Kumar K.V (Arm)
2026-07-06 13:35 ` Marc Zyngier
2026-07-06 13:42 ` Aneesh Kumar K.V
2026-07-06 14:44 ` Marc Zyngier
2026-07-06 6:04 ` [PATCH v5 03/10] dma-mapping: Pass allocation attrs to contiguous allocation helpers Aneesh Kumar K.V (Arm)
2026-07-06 6:04 ` [PATCH v5 04/10] dma-direct: Align CoCo shared DMA allocations to the shared granule size Aneesh Kumar K.V (Arm)
2026-07-06 6:04 ` [PATCH v5 05/10] swiotlb: Align shared IO TLB pools " Aneesh Kumar K.V (Arm)
2026-07-06 6:04 ` [PATCH v5 06/10] swiotlb: Reject misaligned restricted DMA pools for CoCo guests Aneesh Kumar K.V (Arm)
2026-07-06 6:04 ` Aneesh Kumar K.V (Arm) [this message]
2026-07-06 6:04 ` [PATCH v5 08/10] arm64: realm: Move Realm memory encryption ops to RSI code Aneesh Kumar K.V (Arm)
2026-07-06 6:04 ` [PATCH v5 09/10] arm64: realm: Add RHI helper to query IPA state change alignment Aneesh Kumar K.V (Arm)
2026-07-06 6:04 ` [PATCH v5 10/10] arm64: realm: Expose the CCA shared granule size through mem_encrypt ops Aneesh Kumar K.V (Arm)
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=20260706060432.1375570-8-aneesh.kumar@kernel.org \
--to=aneesh.kumar@kernel.org \
--cc=catalin.marinas@arm.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=suzuki.poulose@arm.com \
--cc=tglx@kernel.org \
--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.