linux-kernel - Re: [RFC v1 0/4] Make KHO Stateless

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 for Android: free password hash cracker in your pocket

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

Message-ID: <mafs05xd6d8f9.fsf@kernel.org>
Date: Thu, 25 Sep 2025 14:27:06 +0200
From: Pratyush Yadav <pratyush@...nel.org>
To: Mike Rapoport <rppt@...nel.org>
Cc: Jason Miu <jasonmiu@...gle.com>,  Alexander Graf <graf@...zon.com>,
  Andrew Morton <akpm@...ux-foundation.org>,  Baoquan He <bhe@...hat.com>,
  Changyuan Lyu <changyuanl@...gle.com>,  David Matlack
 <dmatlack@...gle.com>,  David Rientjes <rientjes@...gle.com>,  Jason
 Gunthorpe <jgg@...dia.com>,  Joel Granados <joel.granados@...nel.org>,
  Marcos Paulo de Souza <mpdesouza@...e.com>,  Mario Limonciello
 <mario.limonciello@....com>,  Pasha Tatashin <pasha.tatashin@...een.com>,
  Petr Mladek <pmladek@...e.com>,  "Rafael J . Wysocki"
 <rafael.j.wysocki@...el.com>,  Steven Chen <chenste@...ux.microsoft.com>,
  Yan Zhao <yan.y.zhao@...el.com>,  kexec@...ts.infradead.org,
  linux-kernel@...r.kernel.org,  linux-mm@...ck.org
Subject: Re: [RFC v1 0/4] Make KHO Stateless

On Thu, Sep 25 2025, Mike Rapoport wrote:

> Hi Jason,
>
> On Tue, Sep 16, 2025 at 07:50:15PM -0700, Jason Miu wrote:
>> This series transitions KHO from an xarray-based metadata tracking
>> system with serialization to using page table like data structures
>> that can be passed directly to the next kernel.
>> 
>> The key motivations for this change are to:
>> - Eliminate the need for data serialization before kexec.
>> - Remove the former KHO state machine by deprecating the finalize
>>   and abort states.
>> - Pass preservation metadata more directly to the next kernel via the FDT.
>
> If we pass the preservation metadata directly between the kernels, it means
> that any change to that data structure will break compatibility between the
> new and old kernels. With serialization this is less severe because a more
> recent kernel can relatively easy have backward compatible deserialization.
>
> I'm all for removing KHO state machine, but that does not necessarily mean
> we must remove the serialization of memory persistence metadata?

I think the tables should be treated as the final serialized data
structure, and should get all the same properties that other KHO
serialization formats have like stable binary format, versioning, etc.

It just so happens that the table format lends itself very well to being
serialized on-the-go. When a page is marked as preserved during normal
operation, it is very simple to just allocate all the intermediate
levels and mark the page as reserved. There is no further processing
needed to "serialize" it -- like we need to do with the bitmaps today.

So I don't really see why we should introduce an intermediate processing
step when it is easy to just directly build the serialized data
structure during normal operation.

>
> For example, we can do the serialization at kernel_kexec() time and if we
> want to avoid memory allocations there we might preallocate pages for
> khoser_mem_chunk's as amount of bitmaps grow.
>
> It also would be interesting to see how much time is saved if we remove the
> serialization.

-- 
Regards,
Pratyush Yadav