Re: [PATCH v6 0/9] coco: guest: Enforce host page-size alignment for shared buffers

[Catalin Marinas <catalin.marinas@arm.com>]

On Fri, Sep 04, 2026 at 04:04:43PM +0530, Aneesh Kumar K.V (Arm) wrote:
> This series tightens the alignment requirements for buffers that are shared
> between confidential-computing guests and the host.
> 
> When a guest runs with private memory, buffers shared with the hypervisor
> are not only accessed by the guest. They are also accessed by the host
> kernel, and the host may manage the corresponding shared/private state at a
> granularity larger than the guest page size.
> 
> This matters for CCA systems where the Realm stage-2 mappings managed by
> the RMM can still operate at 4K granularity, while the non-secure host may
> manage the IPA state change at a larger page size, for example 64K. In that
> case, allowing a guest to convert and share only a 4K subrange of a
> host-managed granule is unsafe.
> 
> Architectures such as Arm can detect incorrect accesses to Realm physical
> address space PFNs through GPC faults. However, relying on that as the only
> line of defence is fragile and can still lead to kernel crashes. The risk
> is especially visible for shared buffers that are later mmapped into
> userspace, such as guest_memfd or dma-buf backed allocations. Once
> userspace can access the mapping, the kernel cannot guarantee that
> applications will only touch the intended 4K region rather than the whole
> host page mapped into their address space. Those userspace addresses may
> also be passed back into the kernel and accessed through the linear map,
> resulting in a GPC fault.
> 
> To avoid this, shared buffers must satisfy two constraints:
> 
>   - the address must be aligned to the CoCo shared-granule size
>   - the size must be a multiple of that granule size
> 
> The series adds generic helpers for this:
> 
>   - mem_cc_shared_granule_size()
>   - mem_cc_align_to_shared_granule()
> 
> The generic implementation defaults to PAGE_SIZE. arm64 CCA overrides this
> by querying the host IPA state change granule size through RHI and exposing that
> value through the arm64 memory-encryption operations.
> 
> The patche series update the main shared-buffer allocation paths that can
> be used by private-memory guests:
> 
>   - arm64 set_memory_encrypted()/set_memory_decrypted() now reject unaligned
>     addresses or sizes.
>   - GIC ITS shared allocations are rounded to the shared granule size.
>   - dma-direct and atomic DMA pool allocations use aligned allocation and
>     conversion sizes.
>   - SWIOTLB pools, including dynamic pools, are allocated and converted at the
>     shared granule size.
>   - restricted-dma-pool regions are checked and rejected if firmware did not
>     provide a base and size aligned to the shared granule size.
>   - dma-buf system heap cc-shared allocations require aligned sizes and use at
>     least the required allocation order.

While I understand why you want it, I think that's maintenance burden
longer term. It's already touching about seven allocators (ITS,
dma-direct, CMA, atomic pool, swiotlb, restricted DMA pools, dma-buf).
Although most are in the DMA code, we still need to keep track of their
changes and what else may be coming. Can we even test all these
combinations in a CCA realm?

I assume for trusted devices we can skip this forced alignment.

TBH, I'm tempted not to support this configuration at all, just fail
gracefully if the realm page size doesn't match the host's. However, if
that's a real world configuration, I wonder whether could we leverage
the swiotlb mechanism but with a separate io_tlb_mem as a shared coco
allocator with the right alignment and use this pool when
force_dma_unencrypted() instead of specific alloc_pages() with adjusted
order.

-- 
Catalin