Mon, Feb 23, 2026 at 07:33:07PM +0100, [email protected] wrote: >On Mon, Feb 23, 2026 at 1:51 AM Jiri Pirko <[email protected]> wrote: >> >> From: Jiri Pirko <[email protected]> >> >> Add a new "system_cc_decrypted" dma-buf heap to allow userspace to >> allocate decrypted (shared) memory for confidential computing (CoCo) >> VMs. >> >> On CoCo VMs, guest memory is encrypted by default. The hardware uses an >> encryption bit in page table entries (C-bit on AMD SEV, "shared" bit on >> Intel TDX) to control whether a given memory access is encrypted or >> decrypted. The kernel's direct map is set up with encryption enabled, >> so pages returned by alloc_pages() are encrypted in the direct map >> by default. To make this memory usable for devices that do not support >> DMA to encrypted memory (no TDISP support), it has to be explicitly >> decrypted. A couple of things are needed to properly handle >> decrypted memory for the dma-buf use case: >> >> - set_memory_decrypted() on the direct map after allocation: >> Besides clearing the encryption bit in the direct map PTEs, this >> also notifies the hypervisor about the page state change. On free, >> the inverse set_memory_encrypted() must be called before returning >> pages to the allocator. If re-encryption fails, pages >> are intentionally leaked to prevent decrypted memory from being >> reused as private. >> >> - pgprot_decrypted() for userspace and kernel virtual mappings: >> Any new mapping of the decrypted pages, be it to userspace via >> mmap or to kernel vmalloc space via vmap, creates PTEs independent >> of the direct map. These must also have the encryption bit cleared, >> otherwise accesses through them would see encrypted (garbage) data. >> >> - DMA_ATTR_CC_DECRYPTED for DMA mapping: >> Since the pages are already decrypted, the DMA API needs to be >> informed via DMA_ATTR_CC_DECRYPTED so it can map them correctly >> as unencrypted for device access. >> >> On non-CoCo VMs, the system_cc_decrypted heap is not registered >> to prevent misuse by userspace that does not understand >> the security implications of explicitly decrypted memory. >> >> Signed-off-by: Jiri Pirko <[email protected]> > >Thanks for reworking this! I've not reviewed it super closely, but I >believe it resolves my objection on your first version. > >Few nits/questions below. > >> @@ -296,6 +345,14 @@ static void system_heap_dma_buf_release(struct dma_buf >> *dmabuf) >> for_each_sgtable_sg(table, sg, i) { >> struct page *page = sg_page(sg); >> >> + /* >> + * Intentionally leak pages that cannot be re-encrypted >> + * to prevent decrypted memory from being reused. >> + */ >> + if (buffer->decrypted && >> + system_heap_set_page_encrypted(page)) >> + continue; >> + > >What are the conditions where this would fail? How much of an edge >case is this? I fret this opens a DoS vector if one is able to >allocate from this heap and then stress the system when doing the >free.
>From what I can see, the failure of set_memory_encrypted() is quite rare. Don't see any real DoS scenario for this. All the failures seems to be either theoretical (sanity checks, malicious VMM) or concurrent kexec execution in case of x86/pat. > >Should there be some global list of leaked decrypted pages such that >the mm subsystem could try again later to recover these? swiotlb does the same non-recovery leakage. I belive is it not worth implementing this at this time, > >> diff --git a/include/linux/dma-heap.h b/include/linux/dma-heap.h >> index 648328a64b27..d97b668413c1 100644 >> --- a/include/linux/dma-heap.h >> +++ b/include/linux/dma-heap.h >> @@ -10,6 +10,7 @@ >> #define _DMA_HEAPS_H >> >> #include <linux/types.h> >> +#include <uapi/linux/dma-heap.h> >> >> struct dma_heap; >> >> diff --git a/include/uapi/linux/dma-heap.h b/include/uapi/linux/dma-heap.h >> index a4cf716a49fa..ab95bb355ed5 100644 >> --- a/include/uapi/linux/dma-heap.h >> +++ b/include/uapi/linux/dma-heap.h >> @@ -18,8 +18,7 @@ >> /* Valid FD_FLAGS are O_CLOEXEC, O_RDONLY, O_WRONLY, O_RDWR */ >> #define DMA_HEAP_VALID_FD_FLAGS (O_CLOEXEC | O_ACCMODE) >> >> -/* Currently no heap flags */ >> -#define DMA_HEAP_VALID_HEAP_FLAGS (0ULL) >> +#define DMA_HEAP_VALID_HEAP_FLAGS (0) >> >> /** >> * struct dma_heap_allocation_data - metadata passed from userspace for > >Are these header changes still necessary? Oops, leftovers. Will remove. Thanks! > >thanks >-john
