linux-kernel - Re: [PATCH v6 09/10] liveupdate: kho: Increase metadata bitmap size to PAGE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CA+CK2bCqZFY3HWNj6o2MS4+dz4Re+ekdY_GG1V4GL1Xq1NX_Ug@mail.gmail.com>
Date: Mon, 20 Oct 2025 18:09:57 -0400
From: Pasha Tatashin <pasha.tatashin@...een.com>
To: Mike Rapoport <rppt@...nel.org>
Cc: akpm@...ux-foundation.org, brauner@...nel.org, corbet@....net, 
	graf@...zon.com, jgg@...pe.ca, linux-kernel@...r.kernel.org, 
	linux-kselftest@...r.kernel.org, linux-mm@...ck.org, masahiroy@...nel.org, 
	ojeda@...nel.org, pratyush@...nel.org, rdunlap@...radead.org, tj@...nel.org, 
	jasonmiu@...gle.com, dmatlack@...gle.com, skhawaja@...gle.com
Subject: Re: [PATCH v6 09/10] liveupdate: kho: Increase metadata bitmap size
 to PAGE_SIZE

On Mon, Oct 20, 2025 at 4:03 AM Mike Rapoport <rppt@...nel.org> wrote:
>
> On Sat, Oct 18, 2025 at 01:17:55PM -0400, Pasha Tatashin wrote:
> > Metadata is preserved via 512-bytes, which requires using slabs. Slabs
>
> KHO memory preservation metadata is preserved in 512 byte chunks which
> requires their allocation from slab allocator.

done

>
> > are not safe to be used with KHO because of kfence, and because partial
>
> Please add more details why kfence is not safe here.

Done.

>
> > slabs may lead leaks to the next kernel. Change the size to be
> > PAGE_SIZE.
> >
> > While this change could potentially increase metadata overhead on
> > systems with sparsely preserved memory, this is being mitigated by
> > ongoing work to reduce sparseness during preservation via 1G guest
> > pages. Furthermore, this change aligns with future work on a stateless
> > KHO, which will also use page-sized bitmaps for its radix tree metadata.
>
> With the stateless memory preservation there would be no problem with
> kfence, right?
> Maybe we should accelerate the stateless preservation work?

They are orthogonal, theoretically radix tree could still use the
512-bit bitmaps, but we chose to use page size. Also, Statless KHO
still requires some work, and because it requires removing the
notifiers, it is better if it is based it on top of the other LUO prep
patches.

>
> > Signed-off-by: Pasha Tatashin <pasha.tatashin@...een.com>
>
> --
> Sincerely yours,
> Mike.