From: Mike Rapoport <rppt@kernel.org>
To: Xueyuan Chen <xueyuan.chen21@gmail.com>
Cc: "David Hildenbrand (Arm)" <david@kernel.org>,
akpm@linux-foundation.org, ljs@kernel.org, usama.arif@linux.dev,
ziy@nvidia.com, baolin.wang@linux.alibaba.com,
liam@infradead.org, nico.pache@linux.dev, ryan.roberts@arm.com,
dev.jain@arm.com, baohua@kernel.org, lance.yang@linux.dev,
kas@kernel.org, catalin.marinas@arm.com, will@kernel.org,
mark.rutland@arm.com, linux-arm-kernel@lists.infradead.org,
tglx@kernel.org, mingo@redhat.com, bp@alien8.de,
dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com,
luto@kernel.org, peterz@infradead.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v7 1/3] mm: make persistent huge zero folio read-only
Date: Thu, 10 Sep 2026 10:24:05 +0300 [thread overview]
Message-ID: <aqJbFXjU53_D7SoP@kernel.org> (raw)
In-Reply-To: <CA+qSx6x2-Md9uVZo+HV0z5CfmGPDzhL482eJNnM2VYVtn_e72w@mail.gmail.com>
On Thu, Sep 10, 2026 at 02:22:25PM +0800, Xueyuan Chen wrote:
> On Wed, Sep 9, 2026 at 11:18 PM David Hildenbrand (Arm)
> <david@kernel.org> wrote:
> >
> > On 9/8/26 16:48, Xueyuan Chen wrote:
> > > On Tue, Sep 8, 2026 at 4:30 PM David Hildenbrand (Arm) <david@kernel.org> 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@google.com [1]
> > >>> Link: https://lore.kernel.org/r/0e5b23a6-4895-454a-9dfa-6dc21adc2991@kernel.org [2]
> > >>> Link: https://lore.kernel.org/r/CAHbLzkrXXe7r3n3jXgDKtwZhRqj=jDx9E6dLOULohnhBguvi9A@mail.gmail.com [3]
> > >>>
> > >>> Suggested-by: David Hildenbrand <david@kernel.org>
> > >>> Suggested-by: Usama Arif <usama.arif@linux.dev>
> > >>> Co-developed-by: Lance Yang <lance.yang@linux.dev>
> > >>> Signed-off-by: Lance Yang <lance.yang@linux.dev>
> > >>> Signed-off-by: Xueyuan Chen <xueyuan.chen21@gmail.com>
> > >>> ---
> > >>> 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().
Consistent means leaving highmem check in the caller ...
> 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?
... or checking it in all set_direct_map functions.
I'd keep the check in huge_zero_init() in this patchset.
> Thanks,
> Xueyuan
> > --
> > Cheers,
> >
> > David
--
Sincerely yours,
Mike.
next prev parent reply other threads:[~2026-09-10 7:24 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-01 15:18 [PATCH v7 0/3] mm: make persistent huge zero folio read-only Xueyuan Chen
2026-09-01 15:18 ` [PATCH v7 1/3] " Xueyuan Chen
2026-09-02 20:59 ` Dave Hansen
2026-09-03 1:19 ` Xueyuan Chen
2026-09-03 9:20 ` Mike Rapoport
2026-09-03 14:09 ` Dave Hansen
2026-09-04 3:27 ` Xueyuan Chen
2026-09-03 9:22 ` Mike Rapoport
2026-09-03 12:49 ` Xueyuan Chen
2026-09-06 10:00 ` Mike Rapoport
2026-09-07 1:11 ` Xueyuan Chen
2026-09-07 6:03 ` Mike Rapoport
2026-09-07 11:18 ` David Hildenbrand (Arm)
2026-09-07 14:36 ` Mike Rapoport
2026-09-07 14:48 ` David Hildenbrand (Arm)
2026-09-08 7:35 ` Xueyuan Chen
2026-09-08 8:29 ` David Hildenbrand (Arm)
2026-09-08 14:48 ` Xueyuan Chen
2026-09-09 15:18 ` David Hildenbrand (Arm)
2026-09-10 6:22 ` Xueyuan Chen
2026-09-10 7:24 ` Mike Rapoport [this message]
2026-09-10 7:33 ` David Hildenbrand (Arm)
2026-09-10 7:46 ` Xueyuan Chen
2026-09-01 15:18 ` [PATCH v7 2/3] arm64/mm: add set_direct_map_ro() Xueyuan Chen
2026-09-01 15:18 ` [PATCH v7 3/3] x86/mm: " Xueyuan Chen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aqJbFXjU53_D7SoP@kernel.org \
--to=rppt@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=baohua@kernel.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=bp@alien8.de \
--cc=catalin.marinas@arm.com \
--cc=dave.hansen@linux.intel.com \
--cc=david@kernel.org \
--cc=dev.jain@arm.com \
--cc=hpa@zytor.com \
--cc=kas@kernel.org \
--cc=lance.yang@linux.dev \
--cc=liam@infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=luto@kernel.org \
--cc=mark.rutland@arm.com \
--cc=mingo@redhat.com \
--cc=nico.pache@linux.dev \
--cc=peterz@infradead.org \
--cc=ryan.roberts@arm.com \
--cc=tglx@kernel.org \
--cc=usama.arif@linux.dev \
--cc=will@kernel.org \
--cc=x86@kernel.org \
--cc=xueyuan.chen21@gmail.com \
--cc=ziy@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.