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

From: Xueyuan Chen

Date: Thu Sep 10 2026 - 02:28:29 EST


On Wed, Sep 9, 2026 at 11:18 PM David Hildenbrand (Arm)
<david@xxxxxxxxxx> wrote:
>
> On 9/8/26 16:48, Xueyuan Chen wrote:
> > On Tue, Sep 8, 2026 at 4:30 PM David Hildenbrand (Arm) <david@xxxxxxxxxx> wrote:
> >>
> >> On 9/1/26 17:18, Xueyuan Chen wrote:
> >>> 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 folio read-only in the direct map
> >>> turns such writes into faults instead of silent zero-page corruption.
> >>>
> >>> Add a page-based helper consistent with the existing direct-map interfaces.
> >>> Handle TLB invalidation in the architecture implementation; unsupported
> >>> architectures retain their current behavior.
> >>>
> >>> Protect the folio after initialization. Skip highmem folios, which have no
> >>> permanent direct-map mapping.
> >>>
> >>> Inspired by Jann Horn's read-only zero page work [1] and follow-up
> >>> discussion [3] with Yang Shi.
> >>>
> >>> Link: https://lore.kernel.org/r/20260508-ro-zeropage-v1-1-9808abc20b49@xxxxxxxxxx [1]
> >>> Link: https://lore.kernel.org/r/0e5b23a6-4895-454a-9dfa-6dc21adc2991@xxxxxxxxxx [2]
> >>> Link: https://lore.kernel.org/r/CAHbLzkrXXe7r3n3jXgDKtwZhRqj=jDx9E6dLOULohnhBguvi9A@xxxxxxxxxxxxxx [3]
> >>>
> >>> Suggested-by: David Hildenbrand <david@xxxxxxxxxx>
> >>> Suggested-by: Usama Arif <usama.arif@xxxxxxxxx>
> >>> Co-developed-by: Lance Yang <lance.yang@xxxxxxxxx>
> >>> Signed-off-by: Lance Yang <lance.yang@xxxxxxxxx>
> >>> Signed-off-by: Xueyuan Chen <xueyuan.chen21@xxxxxxxxx>
> >>> ---
> >>> include/linux/set_memory.h | 17 +++++++++++++++++
> >>> mm/huge_memory.c | 13 ++++++++++---
> >>> 2 files changed, 27 insertions(+), 3 deletions(-)
> >>>
> >>> diff --git a/include/linux/set_memory.h b/include/linux/set_memory.h
> >>> index 3fe293cfed8c..ed9ce04b18a1 100644
> >>> --- a/include/linux/set_memory.h
> >>> +++ b/include/linux/set_memory.h
> >>> @@ -54,6 +54,23 @@ static inline bool can_set_direct_map(void)
> >>> #endif
> >>> #endif /* CONFIG_ARCH_HAS_SET_DIRECT_MAP */
> >>>
> >>> +#ifndef set_direct_map_ro
> >>> +/**
> >>> + * set_direct_map_ro - make a direct-map range read-only
> >>> + * @page: first page in the direct-map range
> >>> + * @nr: number of pages in the range
> >>> + *
> >>> + * Make the direct-map range starting at @page read-only and invalidate stale
> >>> + * writable translations before returning.
> >>> + *
> >>> + * Return: 0 on success, or a negative error code on failure.
> >>> + */
> >>> +static inline int set_direct_map_ro(struct page *page, unsigned int nr)
> >>> +{
> >>> + return 0;
> >>> +}
> >>> +#endif
> >>> +
> >>> #ifdef CONFIG_X86_64
> >>> int set_mce_nospec(unsigned long pfn);
> >>> int clear_mce_nospec(unsigned long pfn);
> >>> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> >>> index 54494c3fa983..742283b36d74 100644
> >>> --- a/mm/huge_memory.c
> >>> +++ b/mm/huge_memory.c
> >>> @@ -42,6 +42,7 @@
> >>> #include <linux/pgalloc_tag.h>
> >>> #include <linux/pagewalk.h>
> >>> #include <linux/cleanup.h>
> >>> +#include <linux/set_memory.h>
> >>>
> >>> #include <asm/tlb.h>
> >>> #include "internal.h"
> >>> @@ -291,10 +292,16 @@ static int __init huge_zero_init(void)
> >>> huge_zero_folio = alloc_huge_zero_folio();
> >>> if (!huge_zero_folio) {
> >>> pr_warn("Allocating persistent huge zero folio failed\n");
> >>> - } else {
> >>> - huge_zero_pfn = folio_pfn(huge_zero_folio);
> >>> - count_vm_event(THP_ZERO_PAGE_ALLOC);
> >>> + return 0;
> >>> }
> >>> +
> >>> + huge_zero_pfn = folio_pfn(huge_zero_folio);
> >>> + count_vm_event(THP_ZERO_PAGE_ALLOC);
> >>> +
> >>> + /* Highmem folios have no permanent direct-map mapping to protect. */
> >>> + if (!folio_test_highmem(huge_zero_folio))
> >>> + set_direct_map_ro(folio_page(huge_zero_folio, 0), HPAGE_PMD_NR);
> >>
> >> Assuming we keep the page-based approach, can't we just move the highmem test in
> >> there?
> >
> > Hi David,
> >
> > We can move the check into set_direct_map_ro(). However, on x86,
> > set_direct_map_invalid_noflush() and set_direct_map_default_noflush()
> > also expect callers to exclude highmem pages.
> >
> > Would it make sense to make highmem a documented no-op for those
> > helpers as well, so the direct-map APIs handle it consistently?
>
> I think getting something consistent for now is the most important thing. :)
>
Hi David,

OK, I'll move the highmem check into set_direct_map_ro().

Should I also update the x86 set_direct_map_invalid_noflush() and
set_direct_map_default_noflush() helpers in this series to skip
highmem pages?

Thanks,
Xueyuan
> --
> Cheers,
>
> David