On Fri, Oct 10, 2025 at 01:12:18AM +0200, Pratyush Yadav wrote:

On Thu, Oct 09 2025, Yanjun.Zhu wrote:

quoted

On 10/9/25 10:04 AM, Pasha Tatashin wrote:

quoted

On Thu, Oct 9, 2025 at 11:35 AM Zhu Yanjun [off-list ref] wrote:

quoted

在 2025/10/9 5:01, Pasha Tatashin 写道:

quoted

quoted

quoted

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.

quoted

quoted

quoted

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.

quoted

quoted

quoted

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