linux-kernel - Re: [PATCH v3 19/30] liveupdate: luo

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: <dc71808c-c6a4-434a-aee9-b97601814c92@linux.dev>
Date: Thu, 9 Oct 2025 08:34:50 -0700
From: Zhu Yanjun <yanjun.zhu@...ux.dev>
To: Pasha Tatashin <pasha.tatashin@...een.com>,
 Pratyush Yadav <pratyush@...nel.org>
Cc: jasonmiu@...gle.com, graf@...zon.com, changyuanl@...gle.com,
 rppt@...nel.org, dmatlack@...gle.com, rientjes@...gle.com, corbet@....net,
 rdunlap@...radead.org, ilpo.jarvinen@...ux.intel.com,
 kanie@...ux.alibaba.com, ojeda@...nel.org, aliceryhl@...gle.com,
 masahiroy@...nel.org, akpm@...ux-foundation.org, tj@...nel.org,
 yoann.congal@...le.fr, mmaurer@...gle.com, roman.gushchin@...ux.dev,
 chenridong@...wei.com, axboe@...nel.dk, mark.rutland@....com,
 jannh@...gle.com, vincent.guittot@...aro.org, hannes@...xchg.org,
 dan.j.williams@...el.com, david@...hat.com, joel.granados@...nel.org,
 rostedt@...dmis.org, anna.schumaker@...cle.com, song@...nel.org,
 zhangguopeng@...inos.cn, linux@...ssschuh.net, linux-kernel@...r.kernel.org,
 linux-doc@...r.kernel.org, linux-mm@...ck.org, gregkh@...uxfoundation.org,
 tglx@...utronix.de, mingo@...hat.com, bp@...en8.de,
 dave.hansen@...ux.intel.com, x86@...nel.org, hpa@...or.com,
 rafael@...nel.org, dakr@...nel.org, bartosz.golaszewski@...aro.org,
 cw00.choi@...sung.com, myungjoo.ham@...sung.com, yesanishhere@...il.com,
 Jonathan.Cameron@...wei.com, quic_zijuhu@...cinc.com,
 aleksander.lobakin@...el.com, ira.weiny@...el.com,
 andriy.shevchenko@...ux.intel.com, leon@...nel.org, lukas@...ner.de,
 bhelgaas@...gle.com, wagi@...nel.org, djeffery@...hat.com,
 stuart.w.hayes@...il.com, lennart@...ttering.net, brauner@...nel.org,
 linux-api@...r.kernel.org, linux-fsdevel@...r.kernel.org, saeedm@...dia.com,
 ajayachandra@...dia.com, jgg@...dia.com, parav@...dia.com,
 leonro@...dia.com, witu@...dia.com
Subject: Re: [PATCH v3 19/30] liveupdate: luo_sysfs: add sysfs state
 monitoring


在 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