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

[Lance Yang]

On Thu, May 28, 2026 at 11:43:40AM -0700, Yang Shi wrote:
>
>
>On 5/27/26 9:20 AM, Jann Horn wrote:
>> On Wed, May 27, 2026 at 5:55 PM Dave Hansen <dave.hansen@xxxxxxxxx> wrote:
>>> On 5/26/26 20:56, Xueyuan chen wrote:
>>>> +config READONLY_HUGE_ZERO_FOLIO
>>>> +     bool "Map the huge zero folio read-only in the direct map"
>>>> +     depends on PERSISTENT_HUGE_ZERO_FOLIO
>>>> +     depends on ARCH_HAS_READONLY_HUGE_ZERO_FOLIO
>>>> +     help
>>>> +       The persistent huge zero folio is shared globally, and nothing
>>>> +       should ever change its contents after initialization.
>>>> +
>>>> +       When supported, mark the folio read-only in the direct map so such
>>>> +       writes trigger a fault instead of silently corrupting the zero contents.
>>>> +
>>>> +       If the permission change is not supported, the kernel keeps using
>>>> +       the writable persistent huge zero folio.
>>> I vote for no Kconfig options here. Why? This adds "security" with
>>> _basically_ no extra runtime cost. The runtime cost is, what, usually
>>> one kernel TLB invalidation during boot?
>> Plus potentially a bit more TLB pressure from losing a huge PUD in the
>> linear map, IDK how much we care about that.
>
>This shouldn't be a big issue on ARM64. The most ARM64 machines have 
>linear mapping mapped with PTE if rodata is on. Some machines with 
>BBML2_NOABORT support have linear mapping mapped with PUD/PMD, but those 
>machines typically have large memory, having 512 PMDs instead of 1 PUD 
>shouldn't be a noticeable issue IMHO.

Cool! Thanks Dave, Jann, Yang!

Yeah, that sounds reasonable. No need for another Kconfig option here;
one less knob for people to care about :D

For arm64, I think Yang has it:

1) Without BBML2_NOABORT, rodata=on already forces the linear map down
to PTEs, so nothing really changes there for most machines.

2) With BBML2_NOABORT, this may cost us 512 PMDs instead of one PUD for
that. I don't expect that to be noticeable either ;)

So let's drop the option in the next version.

Cheers, Lance