linux-kernel - Re: [PATCH v2] dma-direct: set decrypted flag for remapped DMA allocations

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAD++jLnfWuoYavrOKoxd6=UvPhuWJmKzHWe76-FM2S+raUnEuw@mail.gmail.com>
Date: Wed, 7 Jan 2026 15:26:16 +0100
From: Linus Walleij <linusw@...nel.org>
To: Jason Gunthorpe <jgg@...pe.ca>
Cc: "Aneesh Kumar K.V (Arm)" <aneesh.kumar@...nel.org>, iommu@...ts.linux.dev, 
	linux-kernel@...r.kernel.org, Marek Szyprowski <m.szyprowski@...sung.com>, 
	Robin Murphy <robin.murphy@....com>, Arnd Bergmann <arnd@...nel.org>, 
	Matthew Wilcox <willy@...radead.org>, Suzuki K Poulose <suzuki.poulose@....com>
Subject: Re: [PATCH v2] dma-direct: set decrypted flag for remapped DMA allocations

On Mon, Jan 5, 2026 at 6:53 PM Jason Gunthorpe <jgg@...pe.ca> wrote:
>
> On Fri, Jan 02, 2026 at 09:20:37PM +0530, Aneesh Kumar K.V (Arm) wrote:
> > Devices that are DMA non-coherent and require a remap were skipping
> > dma_set_decrypted(), leaving DMA buffers encrypted even when the device
> > requires unencrypted access. Move the call after the if (remap) branch
> > so that both the direct and remapped allocation paths correctly mark the
> > allocation as decrypted (or fail cleanly) before use.
>
> This is probably fine, but IMHO, we should be excluding the
> combination of highmem and CC at the kconfig level :\

The only way you can get CMA in highmem is by passing in a highmem
location to the allocator from the command line.

I have a strong urge to just patch CMA to not allow that and see what
happens. Or at least have it print a big fat warning that this will go
away soon.

I think this is only used on legacy ARM32 products that are no longer
maintained, but I might be wrong.

Yours,
Linus Walleij