linux-kernel - Re: [RFC PATCH] liveupdate: list all file handler versions in vmlinux section

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] [day] [month] [year] [list]

Message-ID: <86ecod7zb3.fsf@kernel.org>
Date: Mon, 29 Dec 2025 22:28:32 +0100
From: Pratyush Yadav <pratyush@...nel.org>
To: Alexander Graf <graf@...zon.com>
Cc: Pratyush Yadav <pratyush@...nel.org>,  Arnd Bergmann <arnd@...db.de>,
  "Pasha Tatashin" <pasha.tatashin@...een.com>,  Mike Rapoport
 <rppt@...nel.org>,  "Andrew Morton" <akpm@...ux-foundation.org>,  Dan
 Carpenter <dan.carpenter@...aro.org>,  Jason Gunthorpe <jgg@...dia.com>,
  Samiullah Khawaja <skhawaja@...gle.com>,  David Matlack
 <dmatlack@...gle.com>,  David Rientjes <rientjes@...gle.com>,  Jason Miu
 <jasonmiu@...gle.com>,  <linux-arch@...r.kernel.org>,
  <linux-kernel@...r.kernel.org>,  <linux-mm@...ck.org>,
  <kexec@...ts.infradead.org>
Subject: Re: [RFC PATCH] liveupdate: list all file handler versions in
 vmlinux section

On Sat, Dec 13 2025, Alexander Graf wrote:

> Hi Pratyush,
>
> On 10.12.25 20:26, Pratyush Yadav wrote:
>> As live update evolves, there will be a need to update the serialization
>> formats for the different file types. This could be for adding new
>> features, for supporting a change in behaviour, or to fix bugs.
>>
>> If the current kernel does not understand the same set of versions as
>> the next kernel, live update will inevitably fail. The next kernel will
>> be unable to understand the handed over data and will be unable to
>> restore memory, devices, IOMMU page tables, etc.
>>
>> List the set of versions the kernel understands in a section in vmlinux.
>> This can then be used by userspace tooling to make sure the set of file
>> descriptors it uses have the same version between both kernels. If there
>> is a mismatch, the tooling can catch this early and abort live update
>> before it is too late.
>>
>> The versions are listed in a section called ".liveupdate_versions". The
>> section has a header that contains a magic number and the version of the
>> data format. The list of version strings directly follow this header.
>> Only the version strings are listed, and it is up to userspace to map
>> them to file descriptor types.
>>
>> The format of the section has the same ABI rules as the rest of LUO ABI.
>>
>> Introduce a LIVEUPDATE_FILE_HANDLER macro that makes it easy to define a
>> file handler while also adding its version string to the right section.
>>
>> Signed-off-by: Pratyush Yadav <pratyush@...nel.org>
>
> To support multi-version preservation and resume, how about you add a "profile"
> hint to the handlers? Then you can tag the handlers with "current" and a
> "previous". You then expose one section table with supported versions per
> profile. And that means you can from user space select the local profile to
> serialize and match that against the target profile of the target system.
>
> It also allows you to support more "profiles", such as elaborate downstream
> version combinations, that upstream will not have to care about.

So in essence you want to tie the versions into a "version set"? If you
want to use a new version even for one component, you would create a new
version set.

Interesting idea, but I am curious. Do you see a reason for grouping
versions together in this fashion? Why not let each version be changed
independently?

-- 
Regards,
Pratyush Yadav