On 6/20/2025 8:32 PM, Sean Christopherson wrote:

On Thu, Jun 19, 2025, Mike Rapoport wrote:

quoted

On Thu, Jun 19, 2025 at 02:06:17PM +0200, Christian Brauner wrote:

quoted

On Thu, Jun 19, 2025 at 02:01:22PM +0300, Mike Rapoport wrote:

quoted

On Thu, Jun 19, 2025 at 12:38:25PM +0200, Christian Brauner wrote:

quoted

On Thu, Jun 19, 2025 at 11:13:49AM +0200, Vlastimil Babka wrote:

quoted

On 6/19/25 09:31, Shivank Garg wrote:

quoted

Export anon_inode_make_secure_inode() to allow KVM guest_memfd to create
anonymous inodes with proper security context. This replaces the current
pattern of calling alloc_anon_inode() followed by
inode_init_security_anon() for creating security context manually.

This change also fixes a security regression in secretmem where the
S_PRIVATE flag was not cleared after alloc_anon_inode(), causing
LSM/SELinux checks to be bypassed for secretmem file descriptors.

As guest_memfd currently resides in the KVM module, we need to export this

Could we use the new EXPORT_SYMBOL_GPL_FOR_MODULES() thingy to make this
explicit for KVM?

Oh? Enlighten me about that, if you have a second, please. 

From Documentation/core-api/symbol-namespaces.rst:

The macro takes a comma separated list of module names, allowing only those
modules to access this symbol. Simple tail-globs are supported.

For example::

  EXPORT_SYMBOL_GPL_FOR_MODULES(preempt_notifier_inc, "kvm,kvm-*")

will limit usage of this symbol to modules whoes name matches the given
patterns.

Is that still mostly advisory and can still be easily circumenvented?

Yes and no.  For out-of-tree modules, it's mostly advisory.  Though I can imagine
if someone tries to report a bug because their module is masquerading as e.g. kvm,
then they will be told to go away (in far less polite words :-D).

For in-tree modules, the restriction is much more enforceable.  Renaming a module
to circumvent a restricted export will raise major red flags, and getting "proper"
access to a symbol would require an ack from the relevant maintainers.  E.g. for
many KVM-induced exports, it's not that other module writers are trying to misbehave,
there simply aren't any guardrails to deter them from using a "dangerous" export.
 
The other big benefit I see is documentation, e.g. both for readers/developers to
understand the intent, and for auditing purposes (I would be shocked if there
aren't exports that were KVM-induced, but that are no longer necessary).

And we can utilize the framework to do additional hardening.  E.g. for exports
that exist solely for KVM, I plan on adding wrappers so that the symbols are
exproted if and only if KVM is enabled in the kernel .config[*].  Again, that's
far from perfect, e.g. AFAIK every distro enables KVM, but it should help keep
everyone honest.

[*] https://lore.kernel.org/all/ZzJOoFFPjrzYzKir@google.com (local) 

quoted

The commit message says

   will limit the use of said function to kvm.ko, any other module trying
   to use this symbol will refure to load (and get modpost build
   failures).

To Christian's point, the restrictions are trivial to circumvent by out-of-tree
modules.  E.g. to get access to the above, simply name your module kvm-lol.ko or
whatever.

Thanks for the info.

I have posted the revised patch with EXPORT_SYMBOL_GPL_FOR_MODULES:
https://lore.kernel.org/linux-mm/20250620070328.803704-3-shivankg@amd.com (local)

Please review when you have a chance.

Thanks,
Shivank