[RFC PATCH v3 1/3] mm: make persistent huge zero folio read-only

[Usama Arif]

On Mon,  6 Jul 2026 21:04:38 +0800 Xueyuan Chen <xueyuan.chen21 at gmail.com> wrote:

> From: Xueyuan Chen <xueyuan.chen21 at gmail.com>
> 
> The persistent huge zero folio is shared globally and should stay zero
> after initialization. As Jann Horn pointed out[1], kernel bugs have ended
> up writing to pages that were meant to be read-only, including in
> security-sensitive cases. Making the persistent huge zero folio read-only
> in the direct map turns such writes into faults instead of silent zero-page
> corruption.
> 
> Add set_direct_map_ro_noflush() so mm code can make a direct-map range
> read-only. Use an address-based signature to match ongoing direct-map
> helper work[2], where existing page-based helpers may move the same way.
> The helper is direct-map specific and does not flush TLBs. Architectures
> without direct-map permission support keep existing behavior through the
> generic stub.
> 
> Persistent huge zero folio setup happens during early boot, so no explicit
> TLB flush is needed.
> 
> Inspired by Jann Horn's read-only zero page work[1] and follow-up
> discussion[3] with Yang Shi.
> 
> [1] https://lore.kernel.org/linux-mm/20260508-ro-zeropage-v1-1-9808abc20b49@google.com/
> [2] https://lore.kernel.org/linux-mm/0e5b23a6-4895-454a-9dfa-6dc21adc2991@kernel.org/
> [3] https://lore.kernel.org/linux-mm/CAHbLzkrXXe7r3n3jXgDKtwZhRqj=jDx9E6dLOULohnhBguvi9A@mail.gmail.com/
> 
> Suggested-by: David Hildenbrand <david at kernel.org>
> Co-developed-by: Lance Yang <lance.yang at linux.dev>
> Signed-off-by: Lance Yang <lance.yang at linux.dev>
> Signed-off-by: Xueyuan Chen <xueyuan.chen21 at gmail.com>
> ---
>  include/linux/set_memory.h | 26 ++++++++++++++++++++++++++
>  mm/huge_memory.c           |  9 ++++++++-
>  2 files changed, 34 insertions(+), 1 deletion(-)
> 
> diff --git a/include/linux/set_memory.h b/include/linux/set_memory.h
> index 3030d9245f5a..a905074fb21d 100644
> --- a/include/linux/set_memory.h
> +++ b/include/linux/set_memory.h
> @@ -40,6 +40,22 @@ static inline int set_direct_map_valid_noflush(struct page *page,
>  	return 0;
>  }
>  
> +/**
> + * set_direct_map_ro_noflush - make direct-map mappings read-only
> + * @addr: start address in the direct map
> + * @nr_pages: number of pages starting at @addr
> + *
> + * Make the direct-map mappings for @nr_pages pages starting at @addr
> + * read-only, without flushing TLBs.
> + *
> + * Return: 0 on success or when unsupported, negative error code on failure.
> + */
> +static inline int set_direct_map_ro_noflush(const void *addr,
> +					    unsigned long nr_pages)
> +{
> +	return 0;
> +}
> +
>  static inline bool kernel_page_present(struct page *page)
>  {
>  	return true;
> @@ -56,6 +72,16 @@ static inline bool can_set_direct_map(void)
>  }
>  #define can_set_direct_map can_set_direct_map
>  #endif
> +
> +#ifndef set_direct_map_ro_noflush
> +static inline int set_direct_map_ro_noflush(const void *addr,
> +					    unsigned long nr_pages)
> +{
> +	return 0;
> +}
> +
> +#define set_direct_map_ro_noflush set_direct_map_ro_noflush
> +#endif
>  #endif /* CONFIG_ARCH_HAS_SET_DIRECT_MAP */
>  
>  #ifdef CONFIG_X86_64
> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> index bdd8635922f9..6633217b10dc 100644
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -41,6 +41,7 @@
>  #include <linux/pgalloc.h>
>  #include <linux/pgalloc_tag.h>
>  #include <linux/pagewalk.h>
> +#include <linux/set_memory.h>
>  
>  #include <asm/tlb.h>
>  #include "internal.h"
> @@ -981,8 +982,14 @@ static int __init thp_shrinker_init(void)
>  		 * that get_huge_zero_folio() will most likely not fail as
>  		 * thp_shrinker_init() is invoked early on during boot.
>  		 */
> -		if (!get_huge_zero_folio())
> +		if (!get_huge_zero_folio()) {
>  			pr_warn("Allocating persistent huge zero folio failed\n");
> +			return 0;
> +		}
> +
> +		/* Set up during early boot; no explicit TLB flush is needed here. */
> +		set_direct_map_ro_noflush(folio_address(huge_zero_folio),
> +					  HPAGE_PMD_NR);

Hi,

Can this really skip the TLB flush here?  This runs from a
subsys_initcall, after smp_init() and after the folio was allocated and
zeroed through the writable direct map.  The noflush helper updates the
direct-map PTEs but does not invalidate stale writable kernel TLB entries.

I think we need a TLB flush here?

>  		return 0;
>  	}
>  
> -- 
> 2.49.0
> 
>