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: <e4d1c333-7e22-47ee-81a0-2efc4ca6b17c@amazon.com>
Date: Sat, 13 Dec 2025 16:10:22 +0900
From: Alexander Graf <graf@...zon.com>
To: 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>
CC: <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

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.


Alex





Amazon Web Services Development Center Germany GmbH
Tamara-Danz-Str. 13
10243 Berlin
Geschaeftsfuehrung: Christof Hellmis, Andreas Stieger
Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B
Sitz: Berlin
Ust-ID: DE 365 538 597

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ