Message-ID: <d09881f5-0e0b-4795-99bf-cd3711ee48ab@linux.dev>
Date: Thu, 9 Oct 2025 10:56:33 -0700
From: "Yanjun.Zhu" <yanjun.zhu@...ux.dev>
To: Pasha Tatashin <pasha.tatashin@...een.com>
Cc: Pratyush Yadav <pratyush@...nel.org>, 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


On 10/9/25 10:04 AM, Pasha Tatashin wrote:
> On Thu, Oct 9, 2025 at 11:35 AM Zhu Yanjun <yanjun.zhu@...ux.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

Powered by blists - more mailing lists