From: Xueyuan Chen <xueyuan.chen21@gmail.com>

Hi all,

This series makes the persistent huge zero folio read-only in the direct
map.

The motivation comes from Jann Horn's read-only zero page work[1] and the
follow-up discussion[2] with Yang Shi. As Jann pointed out, the kernel has
had bugs, including security bugs, where pages taken with read-only
semantics were later written to. For the huge zero folio, making the direct
map read-only turns such writes into faults instead of silently corrupting
shared zero contents.

The permission change is best effort. If the architecture cannot safely
make the direct map read-only, the kernel keeps using the writable
persistent huge zero folio.

Patch 1 adds the generic support for making the persistent huge zero folio
read-only. Patches 2 and 3 add arm64 and x86 support.

[1] https://lore.kernel.org/linux-mm/20260508-ro-zeropage-v1-1-9808abc20b49@google.com/
[2] https://lore.kernel.org/linux-mm/CAHbLzkrXXe7r3n3jXgDKtwZhRqj=jDx9E6dLOULohnhBguvi9A@mail.gmail.com/

Xueyuan Chen (3):
  mm: make persistent huge zero folio read-only
  arm64/mm: make huge zero folio read-only in linear map
  x86/mm: make huge zero folio read-only in direct map

 arch/arm64/Kconfig       |  1 +
 arch/arm64/mm/pageattr.c | 16 ++++++++++++++++
 arch/x86/Kconfig         |  1 +
 arch/x86/mm/init.c       | 11 +++++++++++
 include/linux/huge_mm.h  |  5 +++++
 mm/Kconfig               | 17 +++++++++++++++++
 mm/huge_memory.c         | 25 ++++++++++++++++++++++++-
 7 files changed, 75 insertions(+), 1 deletion(-)

-- 
2.47.3

On 5/26/26 20:56, Xueyuan chen wrote:
> The motivation comes from Jann Horn's read-only zero page work[1] and the
> follow-up discussion[2] with Yang Shi. As Jann pointed out, the kernel has
> had bugs, including security bugs, where pages taken with read-only
> semantics were later written to.

My overall concern with this is that it's just a code hack for the huge
zero page and nothing else. It's a total one-off.

I think you need to make the case here that the huge zero page truly is
a special snowflake and deserves a one-off special snowflake solution.
Because it doesn't seem *that* crazy that there are more things that the
kernel dynamically allocates that it wants to keep read only.

Maybe there aren't many things that get mapped to userspace like this.
But the case needs to get made either way.

Hi Dave,

Sorry for the late reply.

On Wed, May 27, 2026 at 08:58:38AM -0700, Dave Hansen wrote:
>On 5/26/26 20:56, Xueyuan chen wrote:
>> The motivation comes from Jann Horn's read-only zero page work[1] and the
>> follow-up discussion[2] with Yang Shi. As Jann pointed out, the kernel has
>> had bugs, including security bugs, where pages taken with read-only
>> semantics were later written to.
>
>My overall concern with this is that it's just a code hack for the huge
>zero page and nothing else. It's a total one-off.

Fair point. I was trying to keep the first version simple, so I
special-cased the persistent huge zero folio. But agreed, the arch side
should not grow a huge-zero-folio-only hook :)

>I think you need to make the case here that the huge zero page truly is
>a special snowflake and deserves a one-off special snowflake solution.
>Because it doesn't seem *that* crazy that there are more things that the
>kernel dynamically allocates that it wants to keep read only.
>
>Maybe there aren't many things that get mapped to userspace like this.
>But the case needs to get made either way.

For RFC v2, I think we should make the arch hook generic, probably
arch_make_folio_readonly(), with a weak default implementation. The
persistent huge zero folio would just be the first user.

But even with a generic helper, we still need to be careful about the
model. I see two possible ones:

1) Treat "read-only in the direct map" as real folio state. Then core MM
has to know about it and carry or clear that state in paths like
migration and freeing. It also makes the possible direct-map split / TLB
cost a more general MM issue, not just a cost tied to one caller ...

2) Only use the helper for folios with a simple lifetime: allocated once,
not migrated, not freed, and not written after they are made read-only.

I'd start with 2. Keeps the arch API generic, but avoids teaching core
MM a new folio state before we have a user that really needs that. The
persistent huge zero folio still works fine with that model. It just
becomes the first user instead of the special case :)

Thoughts?

Cheers, Lance