Introduce a sysfs interface for the Live Update Orchestrator
under /sys/kernel/liveupdate/. This interface provides a way for
userspace tools and scripts to monitor the current state of the LUO
state machine.
The main feature is a read-only file, state, which displays the
current LUO state as a string ("normal", "prepared", "frozen",
"updated"). The interface uses sysfs_notify to allow userspace
listeners (e.g., via poll) to be efficiently notified of state changes.
ABI documentation for this new sysfs interface is added in
Documentation/ABI/testing/sysfs-kernel-liveupdate.
This read-only sysfs interface complements the main ioctl interface
provided by /dev/liveupdate, which handles LUO control operations and
resource management.
Signed-off-by: Pasha Tatashin <pasha.tatashin@soleen.com>
---
.../ABI/testing/sysfs-kernel-liveupdate | 51 ++++++++++
kernel/liveupdate/Kconfig | 18 ++++
kernel/liveupdate/Makefile | 1 +
kernel/liveupdate/luo_core.c | 1 +
kernel/liveupdate/luo_internal.h | 6 ++
kernel/liveupdate/luo_sysfs.c | 92 +++++++++++++++++++
6 files changed, 169 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-kernel-liveupdate
create mode 100644 kernel/liveupdate/luo_sysfs.c
diff --git a/Documentation/ABI/testing/sysfs-kernel-liveupdate b/Documentation/ABI/testing/sysfs-kernel-liveupdate
new file mode 100644
index 000000000000..bb85cbae4943
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-kernel-liveupdate
@@ -0,0 +1,51 @@
+What: /sys/kernel/liveupdate/
+Date: May 2025
+KernelVersion: 6.16.0
+Contact: pasha.tatashin@soleen.com
+Description: Directory containing interfaces to query the live
+ update orchestrator. Live update is the ability to reboot the
+ host kernel (e.g., via kexec, without a full power cycle) while
+ keeping specifically designated devices operational ("alive")
+ across the transition. After the new kernel boots, these devices
+ can be re-attached to their original workloads (e.g., virtual
+ machines) with their state preserved. This is particularly
+ useful, for example, for quick hypervisor updates without
+ terminating running virtual machines.
+
+
+What: /sys/kernel/liveupdate/state
+Date: May 2025
+KernelVersion: 6.16.0
+Contact: pasha.tatashin@soleen.com
+Description: Read-only file that displays the current state of the live
+ update orchestrator as a string. Possible values are:
+
+ "normal" No live update operation is in progress. This is
+ the default operational state.
+
+ "prepared" The live update preparation phase has completed
+ successfully (e.g., triggered via the
+ /dev/liveupdate event). Kernel subsystems have
+ been notified via the %LIVEUPDATE_PREPARE
+ event/callback and should have initiated state
+ saving. User workloads (e.g., VMs) are generally
+ still running, but some operations (like device
+ unbinding or new DMA mappings) might be
+ restricted. The system is ready for the reboot
+ trigger.
+
+ "frozen" The final reboot notification has been sent
+ (e.g., triggered via the 'reboot()' syscall),
+ corresponding to the %LIVEUPDATE_REBOOT kernel
+ event. Subsystems have had their final chance to
+ save state. User workloads must be suspended.
+ The system is about to execute the reboot into
+ the new kernel (imminent kexec). This state
+ corresponds to the "blackout window".
+
+ "updated" The system has successfully rebooted into the
+ new kernel via live update. Restoration of
+ preserved resources can now occur (typically via
+ ioctl commands). The system is awaiting the
+ final 'finish' signal after user space completes
+ restoration tasks.
diff --git a/kernel/liveupdate/Kconfig b/kernel/liveupdate/Kconfig
index f6b0bde188d9..75a17ca8a592 100644
--- a/kernel/liveupdate/Kconfig
+++ b/kernel/liveupdate/Kconfig
@@ -29,6 +29,24 @@ config LIVEUPDATE
If unsure, say N.
+config LIVEUPDATE_SYSFS_API
+ bool "Live Update sysfs monitoring interface"
+ depends on SYSFS
+ depends on LIVEUPDATE
+ help
+ Enable a sysfs interface for the Live Update Orchestrator
+ at /sys/kernel/liveupdate/.
+
+ This allows monitoring the LUO state ('normal', 'prepared',
+ 'frozen', 'updated') via the read-only 'state' file.
+
+ This interface complements the primary /dev/liveupdate ioctl
+ interface, which handles the full update process.
+ This sysfs API may be useful for scripting, or userspace monitoring
+ needed to coordinate application restarts and minimize downtime.
+
+ If unsure, say N.
+
config KEXEC_HANDOVER
bool "kexec handover"
depends on ARCH_SUPPORTS_KEXEC_HANDOVER && ARCH_SUPPORTS_KEXEC_FILE
diff --git a/kernel/liveupdate/Makefile b/kernel/liveupdate/Makefile
index c67fa2797796..47f5d0378a75 100644
--- a/kernel/liveupdate/Makefile
+++ b/kernel/liveupdate/Makefile
@@ -13,3 +13,4 @@ obj-$(CONFIG_KEXEC_HANDOVER) += kexec_handover.o
obj-$(CONFIG_KEXEC_HANDOVER_DEBUG) += kexec_handover_debug.o
obj-$(CONFIG_LIVEUPDATE) += luo.o
+obj-$(CONFIG_LIVEUPDATE_SYSFS_API) += luo_sysfs.o
diff --git a/kernel/liveupdate/luo_core.c b/kernel/liveupdate/luo_core.c
index 64d53b31d6d8..bd07ee859112 100644
--- a/kernel/liveupdate/luo_core.c
+++ b/kernel/liveupdate/luo_core.c
@@ -100,6 +100,7 @@ static inline bool is_current_luo_state(enum liveupdate_state expected_state)
static void __luo_set_state(enum liveupdate_state state)
{
WRITE_ONCE(luo_state, state);
+ luo_sysfs_notify();
}
static inline void luo_set_state(enum liveupdate_state state)
diff --git a/kernel/liveupdate/luo_internal.h b/kernel/liveupdate/luo_internal.h
index 01bd0d3b023b..9091ed04c606 100644
--- a/kernel/liveupdate/luo_internal.h
+++ b/kernel/liveupdate/luo_internal.h
@@ -47,4 +47,10 @@ int luo_file_freeze(u64 token);
int luo_file_cancel(u64 token);
int luo_file_finish(u64 token);
+#ifdef CONFIG_LIVEUPDATE_SYSFS_API
+void luo_sysfs_notify(void);
+#else
+static inline void luo_sysfs_notify(void) {}
+#endif
+
#endif /* _LINUX_LUO_INTERNAL_H */
diff --git a/kernel/liveupdate/luo_sysfs.c b/kernel/liveupdate/luo_sysfs.c
new file mode 100644
index 000000000000..935946bb741b
--- /dev/null
+++ b/kernel/liveupdate/luo_sysfs.c
@@ -0,0 +1,92 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/*
+ * Copyright (c) 2025, Google LLC.
+ * Pasha Tatashin <pasha.tatashin@soleen.com>
+ */
+
+/**
+ * DOC: LUO sysfs interface
+ *
+ * Provides a sysfs interface at ``/sys/kernel/liveupdate/`` for monitoring LUO
+ * state. Live update allows rebooting the kernel (via kexec) while preserving
+ * designated device state for attached workloads (e.g., VMs), useful for
+ * minimizing downtime during hypervisor updates.
+ *
+ * /sys/kernel/liveupdate/state
+ * ----------------------------
+ * - Permissions: Read-only
+ * - Description: Displays the current LUO state string.
+ * - Valid States:
+ * @normal
+ * Idle state.
+ * @prepared
+ * Preparation phase complete (triggered via '/dev/liveupdate'). Resources
+ * checked, state saving initiated via %LIVEUPDATE_PREPARE event.
+ * Workloads mostly running but may be restricted. Ready forreboot
+ * trigger.
+ * @frozen
+ * Final reboot notification sent (triggered via 'reboot'). Corresponds to
+ * %LIVEUPDATE_REBOOT event. Final state saving. Workloads must be
+ * suspended. System about to kexec ("blackout window").
+ * @updated
+ * New kernel booted via live update. Awaiting 'finish' signal.
+ *
+ * Userspace Interaction & Blackout Window Reduction
+ * -------------------------------------------------
+ * Userspace monitors the ``state`` file to coordinate actions:
+ * - Suspend workloads before @frozen state is entered.
+ * - Initiate resource restoration upon entering @updated state.
+ * - Resume workloads after restoration, minimizing downtime.
+ */
+
+#include <linux/kobject.h>
+#include <linux/liveupdate.h>
+#include <linux/sysfs.h>
+#include "luo_internal.h"
+
+static bool luo_sysfs_initialized;
+
+#define LUO_DIR_NAME "liveupdate"
+
+void luo_sysfs_notify(void)
+{
+ if (luo_sysfs_initialized)
+ sysfs_notify(kernel_kobj, LUO_DIR_NAME, "state");
+}
+
+/* Show the current live update state */
+static ssize_t state_show(struct kobject *kobj, struct kobj_attribute *attr,
+ char *buf)
+{
+ return sysfs_emit(buf, "%s\n", luo_current_state_str());
+}
+
+static struct kobj_attribute state_attribute = __ATTR_RO(state);
+
+static struct attribute *luo_attrs[] = {
+ &state_attribute.attr,
+ NULL
+};
+
+static struct attribute_group luo_attr_group = {
+ .attrs = luo_attrs,
+ .name = LUO_DIR_NAME,
+};
+
+static int __init luo_init(void)
+{
+ int ret;
+
+ ret = sysfs_create_group(kernel_kobj, &luo_attr_group);
+ if (ret) {
+ pr_err("Failed to create group\n");
+ return ret;
+ }
+
+ luo_sysfs_initialized = true;
+ pr_info("Initialized\n");
+
+ return 0;
+}
+subsys_initcall(luo_init);
--
2.50.1.565.gc32cd1483b-googOn 8/6/25 6:44 PM, Pasha Tatashin wrote:
> Introduce a sysfs interface for the Live Update Orchestrator
> under /sys/kernel/liveupdate/. This interface provides a way for
> userspace tools and scripts to monitor the current state of the LUO
> state machine.
>
> The main feature is a read-only file, state, which displays the
> current LUO state as a string ("normal", "prepared", "frozen",
> "updated"). The interface uses sysfs_notify to allow userspace
> listeners (e.g., via poll) to be efficiently notified of state changes.
>
> ABI documentation for this new sysfs interface is added in
> Documentation/ABI/testing/sysfs-kernel-liveupdate.
>
> This read-only sysfs interface complements the main ioctl interface
> provided by /dev/liveupdate, which handles LUO control operations and
> resource management.
>
> Signed-off-by: Pasha Tatashin <pasha.tatashin@soleen.com>
> ---
> .../ABI/testing/sysfs-kernel-liveupdate | 51 ++++++++++
> kernel/liveupdate/Kconfig | 18 ++++
> kernel/liveupdate/Makefile | 1 +
> kernel/liveupdate/luo_core.c | 1 +
> kernel/liveupdate/luo_internal.h | 6 ++
> kernel/liveupdate/luo_sysfs.c | 92 +++++++++++++++++++
> 6 files changed, 169 insertions(+)
> create mode 100644 Documentation/ABI/testing/sysfs-kernel-liveupdate
> create mode 100644 kernel/liveupdate/luo_sysfs.c
>
> diff --git a/Documentation/ABI/testing/sysfs-kernel-liveupdate b/Documentation/ABI/testing/sysfs-kernel-liveupdate
> new file mode 100644
> index 000000000000..bb85cbae4943
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-kernel-liveupdate
> @@ -0,0 +1,51 @@
> +What: /sys/kernel/liveupdate/
> +Date: May 2025
> +KernelVersion: 6.16.0
> +Contact: pasha.tatashin@soleen.com
> +Description: Directory containing interfaces to query the live
> + update orchestrator. Live update is the ability to reboot the
> + host kernel (e.g., via kexec, without a full power cycle) while
> + keeping specifically designated devices operational ("alive")
> + across the transition. After the new kernel boots, these devices
> + can be re-attached to their original workloads (e.g., virtual
> + machines) with their state preserved. This is particularly
> + useful, for example, for quick hypervisor updates without
> + terminating running virtual machines.
> +
> +
> +What: /sys/kernel/liveupdate/state
> +Date: May 2025
> +KernelVersion: 6.16.0
> +Contact: pasha.tatashin@soleen.com
> +Description: Read-only file that displays the current state of the live
> + update orchestrator as a string. Possible values are:
> +
> + "normal" No live update operation is in progress. This is
> + the default operational state.
> +
> + "prepared" The live update preparation phase has completed
> + successfully (e.g., triggered via the
> + /dev/liveupdate event). Kernel subsystems have
> + been notified via the %LIVEUPDATE_PREPARE
> + event/callback and should have initiated state
> + saving. User workloads (e.g., VMs) are generally
> + still running, but some operations (like device
> + unbinding or new DMA mappings) might be
> + restricted. The system is ready for the reboot
> + trigger.
> +
> + "frozen" The final reboot notification has been sent
> + (e.g., triggered via the 'reboot()' syscall),
> + corresponding to the %LIVEUPDATE_REBOOT kernel
> + event. Subsystems have had their final chance to
> + save state. User workloads must be suspended.
> + The system is about to execute the reboot into
> + the new kernel (imminent kexec). This state
> + corresponds to the "blackout window".
> +
> + "updated" The system has successfully rebooted into the
> + new kernel via live update. Restoration of
> + preserved resources can now occur (typically via
> + ioctl commands). The system is awaiting the
> + final 'finish' signal after user space completes
> + restoration tasks.
> diff --git a/kernel/liveupdate/Kconfig b/kernel/liveupdate/Kconfig
> index f6b0bde188d9..75a17ca8a592 100644
> --- a/kernel/liveupdate/Kconfig
> +++ b/kernel/liveupdate/Kconfig
> @@ -29,6 +29,24 @@ config LIVEUPDATE
>
> If unsure, say N.
>
> +config LIVEUPDATE_SYSFS_API
> + bool "Live Update sysfs monitoring interface"
> + depends on SYSFS
> + depends on LIVEUPDATE
> + help
> + Enable a sysfs interface for the Live Update Orchestrator
> + at /sys/kernel/liveupdate/.
> +
> + This allows monitoring the LUO state ('normal', 'prepared',
> + 'frozen', 'updated') via the read-only 'state' file.
> +
> + This interface complements the primary /dev/liveupdate ioctl
> + interface, which handles the full update process.
> + This sysfs API may be useful for scripting, or userspace monitoring
> + needed to coordinate application restarts and minimize downtime.
> +
> + If unsure, say N.
> +
> config KEXEC_HANDOVER
> bool "kexec handover"
> depends on ARCH_SUPPORTS_KEXEC_HANDOVER && ARCH_SUPPORTS_KEXEC_FILE
> diff --git a/kernel/liveupdate/Makefile b/kernel/liveupdate/Makefile
> index c67fa2797796..47f5d0378a75 100644
> --- a/kernel/liveupdate/Makefile
> +++ b/kernel/liveupdate/Makefile
> @@ -13,3 +13,4 @@ obj-$(CONFIG_KEXEC_HANDOVER) += kexec_handover.o
> obj-$(CONFIG_KEXEC_HANDOVER_DEBUG) += kexec_handover_debug.o
>
> obj-$(CONFIG_LIVEUPDATE) += luo.o
> +obj-$(CONFIG_LIVEUPDATE_SYSFS_API) += luo_sysfs.o
> diff --git a/kernel/liveupdate/luo_core.c b/kernel/liveupdate/luo_core.c
> index 64d53b31d6d8..bd07ee859112 100644
> --- a/kernel/liveupdate/luo_core.c
> +++ b/kernel/liveupdate/luo_core.c
> @@ -100,6 +100,7 @@ static inline bool is_current_luo_state(enum liveupdate_state expected_state)
> static void __luo_set_state(enum liveupdate_state state)
> {
> WRITE_ONCE(luo_state, state);
> + luo_sysfs_notify();
> }
>
> static inline void luo_set_state(enum liveupdate_state state)
> diff --git a/kernel/liveupdate/luo_internal.h b/kernel/liveupdate/luo_internal.h
> index 01bd0d3b023b..9091ed04c606 100644
> --- a/kernel/liveupdate/luo_internal.h
> +++ b/kernel/liveupdate/luo_internal.h
> @@ -47,4 +47,10 @@ int luo_file_freeze(u64 token);
> int luo_file_cancel(u64 token);
> int luo_file_finish(u64 token);
>
> +#ifdef CONFIG_LIVEUPDATE_SYSFS_API
> +void luo_sysfs_notify(void);
> +#else
> +static inline void luo_sysfs_notify(void) {}
> +#endif
> +
> #endif /* _LINUX_LUO_INTERNAL_H */
> diff --git a/kernel/liveupdate/luo_sysfs.c b/kernel/liveupdate/luo_sysfs.c
> new file mode 100644
> index 000000000000..935946bb741b
> --- /dev/null
> +++ b/kernel/liveupdate/luo_sysfs.c
> @@ -0,0 +1,92 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +/*
> + * Copyright (c) 2025, Google LLC.
> + * Pasha Tatashin <pasha.tatashin@soleen.com>
> + */
> +
> +/**
> + * DOC: LUO sysfs interface
> + *
> + * Provides a sysfs interface at ``/sys/kernel/liveupdate/`` for monitoring LUO
> + * state. Live update allows rebooting the kernel (via kexec) while preserving
> + * designated device state for attached workloads (e.g., VMs), useful for
> + * minimizing downtime during hypervisor updates.
> + *
> + * /sys/kernel/liveupdate/state
> + * ----------------------------
> + * - Permissions: Read-only
> + * - Description: Displays the current LUO state string.
> + * - Valid States:
> + * @normal
> + * Idle state.
> + * @prepared
> + * Preparation phase complete (triggered via '/dev/liveupdate'). Resources
> + * checked, state saving initiated via %LIVEUPDATE_PREPARE event.
> + * Workloads mostly running but may be restricted. Ready forreboot
> + * trigger.
> + * @frozen
> + * Final reboot notification sent (triggered via 'reboot'). Corresponds to
> + * %LIVEUPDATE_REBOOT event. Final state saving. Workloads must be
> + * suspended. System about to kexec ("blackout window").
> + * @updated
> + * New kernel booted via live update. Awaiting 'finish' signal.
> + *
> + * Userspace Interaction & Blackout Window Reduction
> + * -------------------------------------------------
> + * Userspace monitors the ``state`` file to coordinate actions:
> + * - Suspend workloads before @frozen state is entered.
> + * - Initiate resource restoration upon entering @updated state.
> + * - Resume workloads after restoration, minimizing downtime.
> + */
> +
> +#include <linux/kobject.h>
> +#include <linux/liveupdate.h>
> +#include <linux/sysfs.h>
> +#include "luo_internal.h"
> +
> +static bool luo_sysfs_initialized;
> +
> +#define LUO_DIR_NAME "liveupdate"
> +
> +void luo_sysfs_notify(void)
> +{
> + if (luo_sysfs_initialized)
> + sysfs_notify(kernel_kobj, LUO_DIR_NAME, "state");
> +}
> +
> +/* Show the current live update state */
> +static ssize_t state_show(struct kobject *kobj, struct kobj_attribute *attr,
> + char *buf)
> +{
> + return sysfs_emit(buf, "%s\n", luo_current_state_str());
Because the window of kernel live update is short, it is difficult to
statistics how many times the kernel is live updated.
Is it possible to add a variable to statistics the times that the kernel
is live updated?
For example, define a global variable of type atomic_t or u64 in the
core module:
#include <linux/atomic.h>
static atomic_t klu_counter = ATOMIC_INIT(0);
Every time a live update completes successfully, increment the counter:
atomic_inc(&klu_counter);
Then exporting this value through /proc or /sys so that user space can
check it:
static ssize_t klu_counter_show(struct kobject *kobj, struct
kobj_attribute *attr, char *buf)
{
return sprintf(buf, "%d\n", atomic_read(&klu_counter));
}
Yanjun.Zhu
> +}
> +
> +static struct kobj_attribute state_attribute = __ATTR_RO(state);
> +
> +static struct attribute *luo_attrs[] = {
> + &state_attribute.attr,
> + NULL
> +};
> +
> +static struct attribute_group luo_attr_group = {
> + .attrs = luo_attrs,
> + .name = LUO_DIR_NAME,
> +};
> +
> +static int __init luo_init(void)
> +{
> + int ret;
> +
> + ret = sysfs_create_group(kernel_kobj, &luo_attr_group);
> + if (ret) {
> + pr_err("Failed to create group\n");
> + return ret;
> + }
> +
> + luo_sysfs_initialized = true;
> + pr_info("Initialized\n");
> +
> + return 0;
> +}
> +subsys_initcall(luo_init);
On Wed, Oct 08 2025, yanjun.zhu wrote:
> On 8/6/25 6:44 PM, Pasha Tatashin wrote:
>> Introduce a sysfs interface for the Live Update Orchestrator
>> under /sys/kernel/liveupdate/. This interface provides a way for
>> userspace tools and scripts to monitor the current state of the LUO
>> state machine.
>> The main feature is a read-only file, state, which displays the
>> current LUO state as a string ("normal", "prepared", "frozen",
>> "updated"). The interface uses sysfs_notify to allow userspace
>> listeners (e.g., via poll) to be efficiently notified of state changes.
>> ABI documentation for this new sysfs interface is added in
>> Documentation/ABI/testing/sysfs-kernel-liveupdate.
>> This read-only sysfs interface complements the main ioctl interface
>> provided by /dev/liveupdate, which handles LUO control operations and
>> resource management.
>> Signed-off-by: Pasha Tatashin <pasha.tatashin@soleen.com>
[...]
>> +#include <linux/kobject.h>
>> +#include <linux/liveupdate.h>
>> +#include <linux/sysfs.h>
>> +#include "luo_internal.h"
>> +
>> +static bool luo_sysfs_initialized;
>> +
>> +#define LUO_DIR_NAME "liveupdate"
>> +
>> +void luo_sysfs_notify(void)
>> +{
>> + if (luo_sysfs_initialized)
>> + sysfs_notify(kernel_kobj, LUO_DIR_NAME, "state");
>> +}
>> +
>> +/* Show the current live update state */
>> +static ssize_t state_show(struct kobject *kobj, struct kobj_attribute *attr,
>> + char *buf)
>> +{
>> + return sysfs_emit(buf, "%s\n", luo_current_state_str());
>
> Because the window of kernel live update is short, it is difficult to statistics
> how many times the kernel is live updated.
>
> Is it possible to add a variable to statistics the times that the kernel is live
> updated?
The kernel doesn't do the live update on its own. The process is driven
and sequenced by userspace. So if you want to keep statistics, you
should do it from your userspace (luod maybe?). I don't see any need for
this in the kernel.
>
> For example, define a global variable of type atomic_t or u64 in the core
> module:
>
> #include <linux/atomic.h>
>
> static atomic_t klu_counter = ATOMIC_INIT(0);
>
>
> Every time a live update completes successfully, increment the counter:
>
> atomic_inc(&klu_counter);
>
> Then exporting this value through /proc or /sys so that user space can check it:
>
> static ssize_t klu_counter_show(struct kobject *kobj, struct kobj_attribute
> *attr, char *buf)
> {
> return sprintf(buf, "%d\n", atomic_read(&klu_counter));
> }
>
> Yanjun.Zhu
[...]
--
Regards,
Pratyush Yadav
> > Because the window of kernel live update is short, it is difficult to statistics > > how many times the kernel is live updated. > > > > Is it possible to add a variable to statistics the times that the kernel is live > > updated? > > The kernel doesn't do the live update on its own. The process is driven > and sequenced by userspace. So if you want to keep statistics, you > should do it from your userspace (luod maybe?). I don't see any need for > this in the kernel. > One use case I can think of is including information in kdump or the backtrace warning/panic messages about how many times this machine has been live-updated. In the past, I've seen bugs (related to memory corruption) that occurred only after several kexecs, not on the first one. With live updates, especially while the code is being stabilized, I imagine we might have a similar situation. For that reason, it could be useful to have a count in the dmesg logs showing how many times this machine has been live-updated. While this information is also available in userspace, it would be simpler for kernel developers triaging these issues if everything were in one place. Pasha
在 2025/10/9 5:01, Pasha Tatashin 写道: >>> Because the window of kernel live update is short, it is difficult to statistics >>> how many times the kernel is live updated. >>> >>> Is it possible to add a variable to statistics the times that the kernel is live >>> updated? >> The kernel doesn't do the live update on its own. The process is driven >> and sequenced by userspace. So if you want to keep statistics, you >> should do it from your userspace (luod maybe?). I don't see any need for >> this in the kernel. >> > One use case I can think of is including information in kdump or the > backtrace warning/panic messages about how many times this machine has > been live-updated. In the past, I've seen bugs (related to memory > corruption) that occurred only after several kexecs, not on the first > one. With live updates, especially while the code is being stabilized, > I imagine we might have a similar situation. For that reason, it could > be useful to have a count in the dmesg logs showing how many times > this machine has been live-updated. While this information is also > available in userspace, it would be simpler for kernel developers > triaging these issues if everything were in one place. I’m considering this issue from a system security perspective. After the kernel is automatically updated, user-space applications are usually unaware of the change. In one possible scenario, an attacker could replace the kernel with a compromised version, while user-space applications remain unaware of it — which poses a potential security risk. To mitigate this, it would be useful to expose the number of kernel updates through a sysfs interface, so that we can detect whether the kernel has been updated and then collect information about the new kernel to check for possible security issues. Of course, there are other ways to detect kernel updates — for example, by using ftrace to monitor functions involved in live kernel updates — but such approaches tend to have a higher performance overhead. In contrast, adding a simple update counter to track live kernel updates would provide similar monitoring capability with minimal overhead. Yanjun.Zhu > > Pasha -- Best Regards, Yanjun.Zhu
On Thu, Oct 9, 2025 at 11:35 AM Zhu Yanjun <yanjun.zhu@linux.dev> wrote: > > > 在 2025/10/9 5:01, Pasha Tatashin 写道: > >>> Because the window of kernel live update is short, it is difficult to statistics > >>> how many times the kernel is live updated. > >>> > >>> Is it possible to add a variable to statistics the times that the kernel is live > >>> updated? > >> The kernel doesn't do the live update on its own. The process is driven > >> and sequenced by userspace. So if you want to keep statistics, you > >> should do it from your userspace (luod maybe?). I don't see any need for > >> this in the kernel. > >> > > One use case I can think of is including information in kdump or the > > backtrace warning/panic messages about how many times this machine has > > been live-updated. In the past, I've seen bugs (related to memory > > corruption) that occurred only after several kexecs, not on the first > > one. With live updates, especially while the code is being stabilized, > > I imagine we might have a similar situation. For that reason, it could > > be useful to have a count in the dmesg logs showing how many times > > this machine has been live-updated. While this information is also > > available in userspace, it would be simpler for kernel developers > > triaging these issues if everything were in one place. > I’m considering this issue from a system security perspective. After the > kernel is automatically updated, user-space applications are usually > unaware of the change. In one possible scenario, an attacker could > replace the kernel with a compromised version, while user-space > applications remain unaware of it — which poses a potential security risk. > > To mitigate this, it would be useful to expose the number of kernel > updates through a sysfs interface, so that we can detect whether the > kernel has been updated and then collect information about the new > kernel to check for possible security issues. > > Of course, there are other ways to detect kernel updates — for example, > by using ftrace to monitor functions involved in live kernel updates — > but such approaches tend to have a higher performance overhead. In > contrast, adding a simple update counter to track live kernel updates > would provide similar monitoring capability with minimal overhead. Would a print during boot, i.e. when we print that this kernel is live updating, we could include the number, work for you? Otherwise, we could export this number in a debugfs. Pasha
On 10/9/25 10:04 AM, Pasha Tatashin wrote: > On Thu, Oct 9, 2025 at 11:35 AM Zhu Yanjun <yanjun.zhu@linux.dev> wrote: >> >> 在 2025/10/9 5:01, Pasha Tatashin 写道: >>>>> Because the window of kernel live update is short, it is difficult to statistics >>>>> how many times the kernel is live updated. >>>>> >>>>> Is it possible to add a variable to statistics the times that the kernel is live >>>>> updated? >>>> The kernel doesn't do the live update on its own. The process is driven >>>> and sequenced by userspace. So if you want to keep statistics, you >>>> should do it from your userspace (luod maybe?). I don't see any need for >>>> this in the kernel. >>>> >>> One use case I can think of is including information in kdump or the >>> backtrace warning/panic messages about how many times this machine has >>> been live-updated. In the past, I've seen bugs (related to memory >>> corruption) that occurred only after several kexecs, not on the first >>> one. With live updates, especially while the code is being stabilized, >>> I imagine we might have a similar situation. For that reason, it could >>> be useful to have a count in the dmesg logs showing how many times >>> this machine has been live-updated. While this information is also >>> available in userspace, it would be simpler for kernel developers >>> triaging these issues if everything were in one place. >> I’m considering this issue from a system security perspective. After the >> kernel is automatically updated, user-space applications are usually >> unaware of the change. In one possible scenario, an attacker could >> replace the kernel with a compromised version, while user-space >> applications remain unaware of it — which poses a potential security risk. >> >> To mitigate this, it would be useful to expose the number of kernel >> updates through a sysfs interface, so that we can detect whether the >> kernel has been updated and then collect information about the new >> kernel to check for possible security issues. >> >> Of course, there are other ways to detect kernel updates — for example, >> by using ftrace to monitor functions involved in live kernel updates — >> but such approaches tend to have a higher performance overhead. In >> contrast, adding a simple update counter to track live kernel updates >> would provide similar monitoring capability with minimal overhead. > Would a print during boot, i.e. when we print that this kernel is live > updating, we could include the number, work for you? Otherwise, we > could export this number in a debugfs. Since I received a notification that my previous message was not sent successfully, I am resending it. IMO, it would be better to export this number via debugfs. This approach reduces the overhead involved in detecting a kernel live update. If the number is printed in logs instead, the overhead would be higher compared to using debugfs. Thanks a lot. Yanjun.Zhu > > Pasha
On Thu, Oct 09 2025, Yanjun.Zhu wrote: > On 10/9/25 10:04 AM, Pasha Tatashin wrote: >> On Thu, Oct 9, 2025 at 11:35 AM Zhu Yanjun <yanjun.zhu@linux.dev> wrote: >>> >>> 在 2025/10/9 5:01, Pasha Tatashin 写道: >>>>>> Because the window of kernel live update is short, it is difficult to statistics >>>>>> how many times the kernel is live updated. >>>>>> >>>>>> Is it possible to add a variable to statistics the times that the kernel is live >>>>>> updated? >>>>> The kernel doesn't do the live update on its own. The process is driven >>>>> and sequenced by userspace. So if you want to keep statistics, you >>>>> should do it from your userspace (luod maybe?). I don't see any need for >>>>> this in the kernel. >>>>> >>>> One use case I can think of is including information in kdump or the >>>> backtrace warning/panic messages about how many times this machine has >>>> been live-updated. In the past, I've seen bugs (related to memory >>>> corruption) that occurred only after several kexecs, not on the first >>>> one. With live updates, especially while the code is being stabilized, >>>> I imagine we might have a similar situation. For that reason, it could >>>> be useful to have a count in the dmesg logs showing how many times >>>> this machine has been live-updated. While this information is also >>>> available in userspace, it would be simpler for kernel developers >>>> triaging these issues if everything were in one place. Hmm, good point. >>> I’m considering this issue from a system security perspective. After the >>> kernel is automatically updated, user-space applications are usually >>> unaware of the change. In one possible scenario, an attacker could >>> replace the kernel with a compromised version, while user-space >>> applications remain unaware of it — which poses a potential security risk. Wouldn't signing be the way to avoid that? Because if the kernel is compromised then it can very well fake the reboot count as well. >>> >>> To mitigate this, it would be useful to expose the number of kernel >>> updates through a sysfs interface, so that we can detect whether the >>> kernel has been updated and then collect information about the new >>> kernel to check for possible security issues. >>> >>> Of course, there are other ways to detect kernel updates — for example, >>> by using ftrace to monitor functions involved in live kernel updates — >>> but such approaches tend to have a higher performance overhead. In >>> contrast, adding a simple update counter to track live kernel updates >>> would provide similar monitoring capability with minimal overhead. >> Would a print during boot, i.e. when we print that this kernel is live >> updating, we could include the number, work for you? Otherwise, we >> could export this number in a debugfs. > Since I received a notification that my previous message was not sent > successfully, I am resending it. > > IMO, it would be better to export this number via debugfs. This approach reduces > the overhead involved in detecting a kernel live update. > If the number is printed in logs instead, the overhead would be higher compared > to using debugfs. Yeah, debugfs sounds fine. No ABI at least. -- Regards, Pratyush Yadav
On Fri, Oct 10, 2025 at 01:12:18AM +0200, Pratyush Yadav wrote: > On Thu, Oct 09 2025, Yanjun.Zhu wrote: > > > On 10/9/25 10:04 AM, Pasha Tatashin wrote: > >> On Thu, Oct 9, 2025 at 11:35 AM Zhu Yanjun <yanjun.zhu@linux.dev> wrote: > >>> > >>> 在 2025/10/9 5:01, Pasha Tatashin 写道: > >>>>>> Because the window of kernel live update is short, it is difficult to statistics > >>>>>> how many times the kernel is live updated. > >>>>>> > >>>>>> Is it possible to add a variable to statistics the times that the kernel is live > >>>>>> updated? > >>>>> The kernel doesn't do the live update on its own. The process is driven > >>>>> and sequenced by userspace. So if you want to keep statistics, you > >>>>> should do it from your userspace (luod maybe?). I don't see any need for > >>>>> this in the kernel. > >>>>> > >>>> One use case I can think of is including information in kdump or the > >>>> backtrace warning/panic messages about how many times this machine has > >>>> been live-updated. In the past, I've seen bugs (related to memory > >>>> corruption) that occurred only after several kexecs, not on the first > >>>> one. With live updates, especially while the code is being stabilized, > >>>> I imagine we might have a similar situation. For that reason, it could > >>>> be useful to have a count in the dmesg logs showing how many times > >>>> this machine has been live-updated. While this information is also > >>>> available in userspace, it would be simpler for kernel developers > >>>> triaging these issues if everything were in one place. > > Hmm, good point. > > >>> I’m considering this issue from a system security perspective. After the > >>> kernel is automatically updated, user-space applications are usually > >>> unaware of the change. In one possible scenario, an attacker could > >>> replace the kernel with a compromised version, while user-space > >>> applications remain unaware of it — which poses a potential security risk. > > Wouldn't signing be the way to avoid that? Because if the kernel is > compromised then it can very well fake the reboot count as well. > > >>> > >>> To mitigate this, it would be useful to expose the number of kernel > >>> updates through a sysfs interface, so that we can detect whether the > >>> kernel has been updated and then collect information about the new > >>> kernel to check for possible security issues. > >>> > >>> Of course, there are other ways to detect kernel updates — for example, > >>> by using ftrace to monitor functions involved in live kernel updates — > >>> but such approaches tend to have a higher performance overhead. In > >>> contrast, adding a simple update counter to track live kernel updates > >>> would provide similar monitoring capability with minimal overhead. > >> Would a print during boot, i.e. when we print that this kernel is live > >> updating, we could include the number, work for you? Otherwise, we > >> could export this number in a debugfs. > > Since I received a notification that my previous message was not sent > > successfully, I am resending it. > > > > IMO, it would be better to export this number via debugfs. This approach reduces > > the overhead involved in detecting a kernel live update. > > If the number is printed in logs instead, the overhead would be higher compared > > to using debugfs. > > Yeah, debugfs sounds fine. No ABI at least. Do not provide any functionality in debugfs that userspace relies on at all, as odds are, it will not be able to be accessed by most/all of userspace on many systems. It is for debugging only. thanks, greg k-h
On Thu, Oct 09, 2025 at 08:01:13AM -0400, Pasha Tatashin wrote: > > > Because the window of kernel live update is short, it is difficult to statistics > > > how many times the kernel is live updated. > > > > > > Is it possible to add a variable to statistics the times that the kernel is live > > > updated? > > > > The kernel doesn't do the live update on its own. The process is driven > > and sequenced by userspace. So if you want to keep statistics, you > > should do it from your userspace (luod maybe?). I don't see any need for > > this in the kernel. > > > > One use case I can think of is including information in kdump or the > backtrace warning/panic messages about how many times this machine has > been live-updated. In the past, I've seen bugs (related to memory > corruption) that occurred only after several kexecs, not on the first > one. That seems like a reasonable point, to do something like a taint where this is recorded, visible and logged during an oops. Jason
On Wed, Oct 08, 2025 at 06:07:00PM -0700, yanjun.zhu wrote:
> > +#define LUO_DIR_NAME "liveupdate"
> > +
> > +void luo_sysfs_notify(void)
> > +{
> > + if (luo_sysfs_initialized)
> > + sysfs_notify(kernel_kobj, LUO_DIR_NAME, "state");
> > +}
> > +
> > +/* Show the current live update state */
> > +static ssize_t state_show(struct kobject *kobj, struct kobj_attribute *attr,
> > + char *buf)
> > +{
> > + return sysfs_emit(buf, "%s\n", luo_current_state_str());
>
> Because the window of kernel live update is short, it is difficult to
> statistics how many times the kernel is live updated.
>
> Is it possible to add a variable to statistics the times that the kernel is
> live updated?
>
> For example, define a global variable of type atomic_t or u64 in the core
> module:
>
> #include <linux/atomic.h>
>
> static atomic_t klu_counter = ATOMIC_INIT(0);
>
>
> Every time a live update completes successfully, increment the counter:
>
> atomic_inc(&klu_counter);
>
> Then exporting this value through /proc or /sys so that user space can check
> it:
>
> static ssize_t klu_counter_show(struct kobject *kobj, struct kobj_attribute
> *attr, char *buf)
> {
> return sprintf(buf, "%d\n", atomic_read(&klu_counter));
> }
But the value can change right after you read it, so how do you "know"
it is up to date?
What exactly do you want to do with this type of information? What are
you going to do with that information?
thanks,
greg k-h
On Thu, Aug 07, 2025 at 01:44:25AM +0000, Pasha Tatashin wrote: > Introduce a sysfs interface for the Live Update Orchestrator > under /sys/kernel/liveupdate/. This interface provides a way for > userspace tools and scripts to monitor the current state of the LUO > state machine. Now that you have a cdev these files may be more logically placed under the cdev's sysfs and not under kernel? This can be done easially using the attribute mechanisms in the struct device. Again sort of back to my earlier point that everything should be logically linked to the cdev as though there could be many cdevs, even though there are not. It just keeps the code design more properly layered and understanble rather than doing something unique.. Jason
On Tue, Aug 26, 2025 at 4:03 PM Jason Gunthorpe <jgg@nvidia.com> wrote: > > On Thu, Aug 07, 2025 at 01:44:25AM +0000, Pasha Tatashin wrote: > > Introduce a sysfs interface for the Live Update Orchestrator > > under /sys/kernel/liveupdate/. This interface provides a way for > > userspace tools and scripts to monitor the current state of the LUO > > state machine. > > Now that you have a cdev these files may be more logically placed > under the cdev's sysfs and not under kernel? This can be done easially > using the attribute mechanisms in the struct device. > > Again sort of back to my earlier point that everything should be > logically linked to the cdev as though there could be many cdevs, even > though there are not. It just keeps the code design more properly > layered and understanble rather than doing something unique.. I am going to drop this patch entirely, and only rely on "luoctl state" (see https://tinyurl.com/luoddesign) to query the state from "/dev/liveupdate" Pasha
© 2016 - 2026 Red Hat, Inc.