Re: [RFC PATCH] arm64: mm: support set_memory_encrypted/decrypted for vmalloc addresses

[Mike Rapoport <rppt@kernel.org>]

Hi Catalin,

On Tue, Apr 14, 2026 at 05:46:06PM +0100, Catalin Marinas wrote:
> On Fri, Apr 10, 2026 at 02:36:42PM -0700, Kameron Carr wrote:
> > On Friday, April 10, 2026 4:06 AM, Catalin Marinas wrote:
> > > Could you give more details about the user of set_memory_decrypted() on
> > > vmalloc()'ed addresses? I think this came up in the past and I wondered
> > > whether something like GFP_DECRYPTED would be simpler to implement (even
> > > posted a hack but without vmalloc() support). If it is known upfront
> > > that the memory will be decrypted, it's easier/cheaper to do this on the
> > > page allocation time to change the linear map and just use
> > > pgprot_decrypted() for vmap(). No need to rewrite the page table after
> > > mapping the pages.
> [...]
> > In this use case, whether to decrypt the memory can always be known at
> > time of allocation, so a solution like GFP_DECRYPTED is an option.
> > 
> > I think I found the hack you mentioned
> > (https://lore.kernel.org/linux-arm-kernel/ZmNJdSxSz-sYpVgI@arm.com/). The
> > feedback in Michael Kelley's reply covers the key considerations well.
> 
> Yes, that's the thread. It started originally as a GICv3 need
> (eventually we went for genpool).
> 
> > He likely had netvsc's use of vmalloc in mind when he made the point
> > "GFP_DECRYPTED should work for the three memory allocation interfaces and
> > their variants: alloc_pages(), kmalloc(), and vmalloc()." His other
> > points already cover the concerns I had in mind around handling errors
> > from set_memory_decrypted()/encrypted(), etc.
> > 
> > What is the current status of your proposed GFP_DECRYPTED implementation?
> > Is this something you are actively working on?
> 
> Not really. But I've been looking at it again and I think it adds more
> problems than it solves. A GFP flag would be passed down to
> kmem_cache_alloc() and confuse the slab management if some pages are
> encrypted, others not for the same kmem_cache (SLAB_NO_MERGE wouldn't
> help). I wonder whether something like SLAB_DECRYPTED would work better
> for this if we really need it (not aware of any user though).
> 
> Anyway, let's ignore slab for now and look at vmalloc(). I can see
> hv_ringbuffer_init() using an explicit vmap(pgprot_decrypted()). While
> you could do this, it might be better to just add a VM_DECRYPTED flag
> and a few wrappers like vmalloc_decrypted(). It would call
> set_memory_decrypted() for the allocated pages and use
> pgprot_decrypted() for vmap. On vfree(), it will have to set the pages
> back to encrypted. It should be fairly mechanical to do (or a 5 min job
> for an LLM ;)).
 
A GFP + SLAB flag is semantically better than only implementing decrypted
allocations only in vmalloc, but it's surely way more complex and intrusive
and we are running low on gfp flags on 32 bits :)

But I think we can push the _decrypted to kvmalloc() that would do either
kmalloc() + set_memory_decrypted() or vmalloc_decrypted() and it seems that
x86 and drivers could use that instead of alloc_pages() +
set_memory_decrypted().

We also would want also to make x86::set_memory_decrypted() to only accept
linear^w direct map addresses to ensure consistency between architectures.

> -- 
> Catalin
> 

-- 
Sincerely yours,
Mike.