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

[Shanker Donthineni]

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.

Thanks,
Shanker