Re: [PATCH 0/2] Clear shared pages after private-to-shared conversion

[Catalin Marinas]

On Thu, Aug 20, 2026 at 09:20:48AM -0300, Jason Gunthorpe wrote:
> On Thu, Aug 20, 2026 at 11:50:23AM +0100, Steven Price wrote:
> > Arm CCA includes "Memory Encryption Contexts" (MEC) which allows the
> > private and shared data accessible to a guest to have different memory
> > encryption keys. Consequently when converting memory to shared, the
> > memory encryption key used to access the physical page will change.
> > 
> > Both the GICv3 ITS driver and the system_cc_shared dma-buf heap
> > currently allocate memory with __GFP_ZERO and then decrypt it. With MEC
> > the zeroing is done with the wrong encryption key and the data visible
> > after decryption may be ciphertext. The RMM is required to scrub the
> > data, but may perform this scrub with a different encryption key to the
> > eventual key that will be used for shared access.
> > 
> > Fix these two sites by avoiding the __GFP_ZERO during the allocation and
> > performing a clear_pages() call after the decryption.
> 
> Reviewed-by: Jason Gunthorpe <jgg@xxxxxxxxxx>
> 
> This whole set_memory_decrypted() API is awful. It really should be improved.
> 
> alloc_pages_decrypted() ?

At some point I suggested GFP_DECRYPTED but if we don't want to
interfere with the slab allocator, an alloc_pages_decrypted() would do:

https://lore.kernel.org/all/ZmNJdSxSz-sYpVgI@xxxxxxx/

And we had a vmalloc_decrypted() proposal as well that paves the way for
decrupted pages. I forgot what we concluded:

https://lore.kernel.org/all/20260521205834.1012925-1-kameroncarr@xxxxxxxxxxxxxxxxxxx/

Actually, this last series had a lot back and forth around __GFP_ZERO
that's relevant to this series.

I'll comment on v2, I see it posted already.

-- 
Catalin