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 <[email protected]> > > 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/[email protected]/ 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/[email protected]/ 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
