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

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: <a9c31290-3e21-4fbd-bd72-d445701d15a9@arm.com>
Date: Mon, 11 Aug 2025 15:17:17 +0100
From: Robin Murphy <robin.murphy@....com>
To: Shanker Donthineni <sdonthineni@...dia.com>,
 Catalin Marinas <catalin.marinas@....com>, Will Deacon <will@...nel.org>,
 Marek Szyprowski <m.szyprowski@...sung.com>,
 Suzuki K Poulose <suzuki.poulose@....com>,
 Steven Price <steven.price@....com>, linux-arm-kernel@...ts.infradead.org
Cc: Gavin Shan <gshan@...hat.com>, Mike Rapoport <rppt@...nel.org>,
 Vikram Sethi <vsethi@...dia.com>, Jason Sequeira <jsequeira@...dia.com>,
 Dev Jain <dev.jain@....com>, David Rientjes <rientjes@...gle.com>,
 linux-kernel@...r.kernel.org, iommu@...ts.linux.dev
Subject: Re: [RESEND PATCH 2/2] arm64: Add encrypt/decrypt support for vmalloc
 regions

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.