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: <0dccea36-0d79-42cc-a12f-5a890061ff59@app.fastmail.com>
Date: Wed, 07 Jan 2026 16:03:54 +0100
From: "Arnd Bergmann" <arnd@...nel.org>
To: "Linus Walleij" <linusw@...nel.org>, "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>,
 "Matthew Wilcox" <willy@...radead.org>,
 "Suzuki K Poulose" <suzuki.poulose@....com>,
 "Dmitry Osipenko" <digetx@...il.com>, "Thierry Reding" <treding@...dia.com>
Subject: Re: [PATCH v2] dma-direct: set decrypted flag for remapped DMA allocations

On Wed, Jan 7, 2026, at 15:26, Linus Walleij wrote:
> 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.

What about those that declare a "shared-dma-pool" node in DT?

I don't quite understand how the alloc-ranges are picked here, but
from what I can tell, most of them are intentionally limiting
themselves to the smallest lowmem area (CONFIG_VMSPLIT_3G), while
at least three others seem to intentionally pick a highmem area,
specifically these tegra114 and tegra20 (but not tegra30) devices:

arch/arm/boot/dts/nvidia/tegra114-asus-tf701t.dts-                      alloc-ranges = <0x80000000 0x30000000>;
arch/arm/boot/dts/nvidia/tegra20-acer-a500-picasso.dts-                 alloc-ranges = <0x30000000 0x10000000>;
arch/arm/boot/dts/nvidia/tegra20-asus-transformer-common.dtsi-                  alloc-ranges = <0x30000000 0x10000000>;

[cc Dmitry and Thierry in case they remember why this was done]

With my proposed change to increase the default lowmem size,
all of these would be in the lowmem area after all, so it does
not actually matter, but there are probably other out-of-tree
dtbs doing the same thing.

> 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.

It's hard to know, I can definitely think of reasons to do this
intentionally on machines that are still supported, using either
a custom dtb or a custom command line. We can of course decide to not
support this configuration any more, and move the CMA area down
in those cases.

      Arnd