On 23/03/2026 17:51, David Hildenbrand (Arm) wrote:
On 3/17/26 15:10, Kalyazin, Nikita wrote:
From: Nikita Kalyazin <[email protected]>

Let's provide folio_{zap,restore}_direct_map helpers as preparation for
supporting removal of the direct map for guest_memfd folios.
In folio_zap_direct_map(), flush TLB to make sure the data is not
accessible.

The new helpers need to be accessible to KVM on architectures that
support guest_memfd (x86 and arm64).

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

Maybe mention that there might be a double TLB flush on some
architectures, but that that is something to figure out later. Same
behavior in secretmem code where this will be used next.

Added, thanks.



Signed-off-by: Nikita Kalyazin <[email protected]>
---
  include/linux/set_memory.h | 13 ++++++++++++
  mm/memory.c                | 42 ++++++++++++++++++++++++++++++++++++++
  2 files changed, 55 insertions(+)

diff --git a/include/linux/set_memory.h b/include/linux/set_memory.h
index 1a2563f525fc..24caea2931f9 100644
--- a/include/linux/set_memory.h
+++ b/include/linux/set_memory.h
@@ -41,6 +41,15 @@ static inline int set_direct_map_valid_noflush(const void 
*addr,
       return 0;
  }

+static inline int folio_zap_direct_map(struct folio *folio)
+{
+     return 0;

Should we return -ENOSYS here or similar?

I'm not very certain about it because set_direct_map_* return 0 in this case. Do we want them to behave differently?


+}
+
+static inline void folio_restore_direct_map(struct folio *folio)
+{
+}
+
  static inline bool kernel_page_present(struct page *page)
  {
       return true;
@@ -57,6 +66,10 @@ static inline bool can_set_direct_map(void)
  }
  #define can_set_direct_map can_set_direct_map
  #endif
+
+int folio_zap_direct_map(struct folio *folio);
+void folio_restore_direct_map(struct folio *folio);
+
  #endif /* CONFIG_ARCH_HAS_SET_DIRECT_MAP */

  #ifdef CONFIG_X86_64
diff --git a/mm/memory.c b/mm/memory.c
index 07778814b4a8..cab6bb237fc0 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -78,6 +78,7 @@
  #include <linux/sched/sysctl.h>
  #include <linux/pgalloc.h>
  #include <linux/uaccess.h>
+#include <linux/set_memory.h>

  #include <trace/events/kmem.h>

@@ -7478,3 +7479,44 @@ void vma_pgtable_walk_end(struct vm_area_struct *vma)
       if (is_vm_hugetlb_page(vma))
               hugetlb_vma_unlock_read(vma);
  }
+
+#ifdef CONFIG_ARCH_HAS_SET_DIRECT_MAP
+/**
+ * folio_zap_direct_map - remove a folio from the kernel direct map
+ * @folio: folio to remove from the direct map
+ *
+ * Removes the folio from the kernel direct map and flushes the TLB.  This may
+ * require splitting huge pages in the direct map, which can fail due to memory
+ * allocation.

Best to mention

"So far, only order-0 folios are supported." and then ...

+ *
+ * Return: 0 on success, or a negative error code on failure.
+ */
+int folio_zap_direct_map(struct folio *folio)
+{
+     const void *addr = folio_address(folio);
+     int ret;
+

if (folio_test_large(folio))
         return -EINVAL;

Added, thanks.



With that,

Acked-by: David Hildenbrand (Arm) <[email protected]>

Thank you.


--
Cheers,

David


Reply via email to