Re: [PATCH] powerpc: Export set_memory_encrypted and set_memory_decrypted

Re: [PATCH] powerpc: Export set_memory_encrypted and set_memory_decrypted

[Christoph Hellwig]

On Fri, May 22, 2026 at 03:58:53PM -0700, T.J. Mercier wrote:
> After commit fd55edff8a0a ("dma-buf: heaps: system: Turn the heap into a
> module") the system dma-buf heaps can be built as a module. The
> system_cc_shared heap uses set_memory_encrypted and set_memory_decrypted
> but those functions are not exported on powerpc. This can result in a
> build error like:

I'd much rather revert the above commit.  Yes, x86 has exported these
since 2017, but that's a really bad idea, and we should fix it instead
of spreading the export.

Setting memory decrypted is a dangerous operations and should only
be available to core code.  We should have various allocators for
decrypted code, but not export the functionality to random code.

Re: [PATCH] powerpc: Export set_memory_encrypted and set_memory_decrypted

[Jason Gunthorpe]

On Sun, May 24, 2026 at 11:21:33PM -0700, Christoph Hellwig wrote:
> On Fri, May 22, 2026 at 03:58:53PM -0700, T.J. Mercier wrote:
> > After commit fd55edff8a0a ("dma-buf: heaps: system: Turn the heap into a
> > module") the system dma-buf heaps can be built as a module. The
> > system_cc_shared heap uses set_memory_encrypted and set_memory_decrypted
> > but those functions are not exported on powerpc. This can result in a
> > build error like:
> 
> I'd much rather revert the above commit.  Yes, x86 has exported these
> since 2017, but that's a really bad idea, and we should fix it instead
> of spreading the export.
> 
> Setting memory decrypted is a dangerous operations and should only
> be available to core code.  We should have various allocators for
> decrypted code, but not export the functionality to random code.

At the very least an EXPORT_SYMBOL_NS.

Looks like there are about 3 modules using it already..

Jason

Re: [PATCH] powerpc: Export set_memory_encrypted and set_memory_decrypted

[Borislav Petkov]

On Wed, May 27, 2026 at 01:07:16PM -0300, Jason Gunthorpe wrote:
> > Setting memory decrypted is a dangerous operations and should only
> > be available to core code.  We should have various allocators for
> > decrypted code, but not export the functionality to random code.
> 
> At the very least an EXPORT_SYMBOL_NS.
> 
> Looks like there are about 3 modules using it already..

Looks like more to me...

In any case, we exported them back then for some framebuffer things:

95cf9264d5f3 ("x86, drm, fbdev: Do not specify encrypted memory for video mappings")

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Re: [PATCH] powerpc: Export set_memory_encrypted and set_memory_decrypted

[Christoph Hellwig]

On Wed, May 27, 2026 at 11:15:49AM -0700, Borislav Petkov wrote:
> On Wed, May 27, 2026 at 01:07:16PM -0300, Jason Gunthorpe wrote:
> > > Setting memory decrypted is a dangerous operations and should only
> > > be available to core code.  We should have various allocators for
> > > decrypted code, but not export the functionality to random code.
> > 
> > At the very least an EXPORT_SYMBOL_NS.
> > 
> > Looks like there are about 3 modules using it already..
> 
> Looks like more to me...
> 
> In any case, we exported them back then for some framebuffer things:
> 
> 95cf9264d5f3 ("x86, drm, fbdev: Do not specify encrypted memory for video mappings")

Which is exactly one of these things that should not happen - mapping
random I/O memory without the proper helpers..