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: <aUFdp_fsGCNrFf76@dev-dsk-epetron-1c-1d4d9719.eu-west-1.amazon.com>
Date: Tue, 16 Dec 2025 13:24:55 +0000
From: Evangelos Petrongonas <epetron@...zon.de>
To: Pratyush Yadav <pratyush@...nel.org>
CC: 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 Thu, Dec 11, 2025 at 01:26:22PM +0900 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>
> ---
> 
> diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
> index e04d56a5332e..a474c9529a5f 100644
> --- a/include/asm-generic/vmlinux.lds.h
> +++ b/include/asm-generic/vmlinux.lds.h
> @@ -342,6 +342,17 @@ defined(CONFIG_AUTOFDO_CLANG) || defined(CONFIG_PROPELLER_CLANG)
>  #define THERMAL_TABLE(name)
>  #endif
>  
> +#ifdef CONFIG_LIVEUPDATE
> +#define LIVEUPDATE_VERSIONS						\
> +	. = ALIGN(8);							\
> +	.liveupdate_versions : AT(ADDR(.liveupdate_versions) - LOAD_OFFSET) {	\
> +		KEEP(*(.liveupdate_sec_hdr))				\
> +		KEEP(*(.liveupdate_versions))				\
> +	}
> +#else
> +#define LIVEUPDATE_VERSIONS
> +#endif
> +
>  #define KERNEL_DTB()							\
>  	STRUCT_ALIGN();							\
>  	__dtb_start = .;						\
> @@ -544,6 +555,7 @@ defined(CONFIG_AUTOFDO_CLANG) || defined(CONFIG_PROPELLER_CLANG)
>  	RO_EXCEPTION_TABLE						\
>  	NOTES								\
>  	BTF								\
> +	LIVEUPDATE_VERSIONS						\
>  									\
>  	. = ALIGN((align));						\
>  	__end_rodata = .;
> diff --git a/include/linux/kho/abi/luo.h b/include/linux/kho/abi/luo.h
> index 4a1cc6a5f3f8..57ef75695f62 100644
> --- a/include/linux/kho/abi/luo.h
> +++ b/include/linux/kho/abi/luo.h
> @@ -244,4 +244,38 @@ struct luo_flb_ser {
>  #define LIVEUPDATE_TEST_FLB_COMPATIBLE(i)	"liveupdate-test-flb-v" #i
>  #endif
>  
> +#define LIVEUPDATE_VER_HDR_MAGIC 0x4c565550 /* 'LVUP' */
> +#define LIVEUPDATE_VER_HDR_VER   1
> +
> +/**
> + * struct liveupdate_ver_hdr - Header of vmlinux section with version lists
> + * @magic:     Magic number.
> + * @version:   Version of the header format.
> + *
> + * This struct is the header for the vmlinux section ".liveupdate_versions". The
> + * section contains the list of file handler versions that the kernel can
> + * support.
> + */
> +struct liveupdate_ver_hdr {
> +	u32 magic;
> +	u32 version;
> +};

I believe we are going to have two main classes of LUO objects that are
going to participate in Liveupdates, when it comes to their criticality

- Core/Mandatory components. Theese components are necessary for the
kexec to be succesfull. Think components like IOMMU page tables, as
you have mentioned.

- Acceleration/Optional Components. As we strive to minimise the blackout
time, we will trying to persist more and more state across kexec, that
are currently being initialised from scratch during boot. Thing of
certain optimisation like PCI onboarding (at least parts of it)
and the PCI Config Space Cache. If theese components are incompatible
between versions, we might still want to proceed, with the LU, at the
cost of increased blackout time.

I believe it will be quite usefull to be able to have the ability
to differentiate between the two.

> +
> +/**
> + * struct liveupdate_ver_table - Table of file handler versions that the kernel
> + * can support.
> + *
> + * @hdr:        Table header.
> + * @versions:   List of versions the kernel supports. The strings ate
> + *              NUL-terminated, but to keep the format simpler always take up
> + *              LIVEUPDATE_HNDL_COMPAT_LENGTH bytes.
> + *
> + * The list of versions immediately follows the header. The number of versions
> + * are determined by section length.
> + */
> +struct liveupdate_ver_table {
> +	struct liveupdate_ver_hdr hdr;
> +	char versions[][LIVEUPDATE_HNDL_COMPAT_LENGTH];
> +};
> +
> -- 
> 2.43.0
>

Kind Regards,
Evangelos



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