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++jL=fwYJ6onVsrM_=ffuqwR2zLJLJNSWWmDM+Ov02Gf-DyQ@mail.gmail.com>
Date: Wed, 7 Jan 2026 18:41:35 +0100
From: Linus Walleij <linusw@...nel.org>
To: Arnd Bergmann <arnd@...nel.org>
Cc: Jason Gunthorpe <jgg@...pe.ca>, "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 4:04 PM Arnd Bergmann <arnd@...nel.org> wrote:
> 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?

Yeah that thing is really obscuring the view :(

That's usually just defining a size and alignment and pick out of the
existing core memory, sometimes an 'alloc-range'.

The actual memory extents resolution happens in
__reserved_mem_alloc_size in drivers/of/of_reserved_mem.c.
If you didn't define an alloc-range it will pick from base 0
so as low in lowmem as it can get, essentially. (AFAICT)
And I guess it will usually get some really low lowmem
then?

If an alloc-range is specified __reserved_mem_alloc_in_range()
is called and that is considerably less predictable and seems
to mostly concern itself with other fixed allocations and not
whether they are in highmem or lowmem, and might even
theoretically cross over the lowmem/highmem border
AFAICT, which would be a major headache so I don't think
that happens in practice.

I did a grep 'alloc-ranges' but now I'm a bit slow in the head
so cannot really figure out if these will end up outside the
linear map or not.

Yours,
Linus Walleij