[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5d0c582f-7e1a-4623-90d9-1dd6db443473@suse.cz>
Date: Tue, 25 Nov 2025 19:06:53 +0100
From: Vlastimil Babka <vbabka@...e.cz>
To: Michal Hocko <mhocko@...e.com>, Joshua Hahn <joshua.hahnjy@...il.com>,
Kees Cook <kees@...nel.org>, "Gustavo A. R. Silva" <gustavoars@...nel.org>,
"linux-hardening@...r.kernel.org" <linux-hardening@...r.kernel.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>, Mike Rapoport
<rppt@...nel.org>, linux-kernel@...r.kernel.org, linux-mm@...ck.org,
kernel-team@...a.com
Subject: Re: [PATCH v2 2/2] mm/mm_init: decouple page checking and
init_on_{alloc, free}
On 11/25/25 09:45, Michal Hocko wrote:
> On Mon 24-11-25 14:54:07, Joshua Hahn wrote:
>> init_on_alloc and init_on_free protect the kernel by initializing
>> allocated and freed pages to 0 on allocation time / deletion.
>> Commit 700d2e9a36b93601270c1e15550acde2521386c5 ("mm, page_alloc: reduce
>> page alloc/free sanity checks") removed page checking from hot pcp
>> drain and refill paths, and instead coupled it with CONFIG_DEBUG_VM,
>> debug_pagealloc, page poisoning, and init_on_{alloc, free}.
>>
>> As the commit suggests, the first three turn the kernel into a debug
>> kernel, while the last hardens the kernel against leaking sensitive memory.
>> While enabling page checking is relatively low-cost and tying it
>> together with page initialization is not unreasonable, it does feel like
>> a bit of a side-effect, rather than an obvious consequence.
>>
>> With page checking now pulled out as a boot time parameter that can be
>> set independently, let's decouple page checking and init_on_alloc and
>> init_on_free.
>>
>> As a direct side effect, systems that have init_on_alloc or init_on_free
>> will no longer have page checking enabled by default; they will either
>> have to pass the check_pages boot parameter, build the kernel with
>> CONFIG_DEBUG_VM, or enable debug_pagealloc / page poisoning.
>
> How come this will not break existing users? What is an actual upside to
> get for the risk involved?
+Cc hardening people for input if they are fine with the decoupling and if
docs for hardening recommendations or something similar needs updating
The upside is mainly reducing the side effects i.e. being more explicit than
implicit. In practice I'd however assume people running init_on_alloc/free
and paying the cost also want to do page flags checking anyway. The more
important patch here is 1/2.
Powered by blists - more mailing lists