Re: [RESEND PATCH 2/2] arm64: Add encrypt/decrypt support for vmalloc regions

[Robin Murphy]

On 11/08/2025 2:05 pm, Shanker Donthineni wrote:
> Hi Robin,
>
> On 8/11/25 07:31, Robin Murphy wrote:
> > External email: Use caution opening links or attachments
> >
> >
> > On 2025-08-11 1:50 am, Shanker Donthineni wrote:
> > > On ARM64 systems with CCA (Confidential Compute Architecture) enabled,
> > > the kernel may need to change the encryption attributes of memory
> > > regions. The existing implementation of set_memory_encrypted() and
> > > set_memory_decrypted() assumes that the input address is part of the
> > > linear mapping region '__is_lm_address()', and fails with -EINVAL
> > > otherwise.
> > >
> > > This breaks use cases where the memory region resides in the vmalloc
> > > area, which is mapped in non-linear mapping region.
> > >
> > > This patch introduces a new helper, realm_set_memory(), which detects
> > > whether the given address is from a non-linear mapping. If so, it uses
> > > vmalloc_to_page() to resolve each page’s physical address and applies
> > > attribute changes one page at a time. For the linear address regions,
> > > it maintains the existing fast-path.
> > >
> > > This change ensures that encrypted/decrypted memory attribute updates
> > > correctly for all memory regions, including those allocated via vmap(),
> > > module allocations, or other vmalloc-backed paths.
> > >
> > > Call stack of Realm crash, QEMU hypervisor + NVME device (emulated):
> > >   ...
> > >   Freeing unused kernel memory: 6336K
> > >   Run /sbin/init as init process
> > >   Internal error: synchronous external abort: 0000000096000250 [#1]  SMP
> > >   Modules linked in:
> > >   CPU: 0 UID: 0 PID: 64 Comm: lsblk Not tainted 6.15.5 #2 PREEMPT(undef)
> > >   Hardware name: linux,dummy-virt (DT)
> > >   pstate: 43400005 (nZcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--)
> > >   pc : __pi_memset_generic+0x16c/0x188
> > >   lr : dma_alloc_from_pool+0xd0/0x1b8
> > >   sp : ffff80008335b350
> > >   x29: ffff80008335b350 x28: ffff800083162000 x27: ffff80008335b3c0
> > >   x26: ffff80008144f000 x25: ffff8000801a27e8 x24: ffff800081e14000
> > >   x23: ffffc1ffc0000000 x22: 0000000000001000 x21: ffff800081458310
> > >   x20: 0000000042a40000 x19: ffff00000232fcc0 x18: 0000000000200000
> > >   x17: 00000000000120c0 x16: ffff0000795520c0 x15: 0000000000000000
> > >   x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000
> > >   x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000
> > >   x8 : ffff800083162000 x7 : 0000000000000000 x6 : 000000000000003f
> > >   x5 : 0000000000000040 x4 : 0000000000000000 x3 : 0000000000000004
> > >   x2 : 0000000000000fc0 x1 : 0000000000000000 x0 : ffff800083162000
> > >   Call trace:
> > >     __pi_memset_generic+0x16c/0x188 (P)
> > >     dma_direct_alloc_from_pool+0xc4/0x230
> >
> > But isn't that exactly the case that patch #1 is supposed to have fixed?
> >  From a quick scan of set_memory_decrypted() callers I don't see
> > anything obvious jumping out - can you clarify who you think needs this
> > for reasons other than papering over bugs in the DMA layer?
>
> Patch #1 fixes the passing of the correct mapped address (via 
> vmalloc/vmap),
> prevent this specific crash. However, Realm boot still fails because
> __set_memory_enc_dec() returns -EINVAL when the requested address is not
> part of the linear mapping. Both patches are required to fully resolve the
> issue. Patch #2 is to support shared (decrypted) pages in vmalloced 
> regions.

Right, sorry for perhaps being unclear - the half-formed idea I was 
heading towards is that if patch #1 doesn't actually make DMA pools work 
then I'm not necessarily sure it's the right fix as-is.

In fact, looking at the code again, I think it probably shouldn't be 
relying on set_memory at all in the remap case, but instead using 
pgprot_decrypted(), same as the regular non-pool path in dma_direct_alloc().

Thanks,
Robin.