From: Patrick Roy <patrick.roy@linux.dev>

Use the per-module export functionality to allow KVM (and only KVM)
access to set_direct_map_valid_noflush(). This allows guest_memfd to
remove its memory from the direct map, even if KVM is built as a module.

Only do this on x86, as only x86 and arm64 support guest_memfd, and
arm64 does not support building KVM as a module.

Direct map removal gives guest_memfd the same protection that
memfd_secret enjoys, such as hardening against Spectre-like attacks
through in-kernel gadgets.

Signed-off-by: Patrick Roy <patrick.roy@linux.dev>
Signed-off-by: Nikita Kalyazin <kalyazin@amazon.com>
---
 arch/x86/mm/pat/set_memory.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/mm/pat/set_memory.c b/arch/x86/mm/pat/set_memory.c
index 970981893c9b..a7a88b598d99 100644
--- a/arch/x86/mm/pat/set_memory.c
+++ b/arch/x86/mm/pat/set_memory.c
@@ -2655,6 +2655,7 @@ int set_direct_map_valid_noflush(struct page *page, unsigned nr, bool valid)
 
 	return __set_pages_np(page, nr);
 }
+EXPORT_SYMBOL_FOR_MODULES(set_direct_map_valid_noflush, "kvm");
 
 #ifdef CONFIG_DEBUG_PAGEALLOC
 void __kernel_map_pages(struct page *page, int numpages, int enable)
-- 
2.50.1

On 12/5/25 08:57, Kalyazin, Nikita wrote:
...
> +EXPORT_SYMBOL_FOR_MODULES(set_direct_map_valid_noflush, "kvm");

I think this export is a bad idea. The interface is abhorrent enough,
but exporting it just invites abuse and bugs.

I think what this really needs is a pair of helpers that are just:

	folio_zap_direct_map()
and
	folio_restore_direct_map()

that take a folio. *Those* can get exported to modules and those should
internally flush the TLB and not expect callers to do it.