linux-kernel - Re: [PATCH v2 2/2] kexec: history: track kexec boot counter

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: <2vxza4yghv6j.fsf@kernel.org>
Date: Wed, 14 Jan 2026 19:05:08 +0000
From: Pratyush Yadav <pratyush@...nel.org>
To: Breno Leitao <leitao@...ian.org>
Cc: Pratyush Yadav <pratyush@...nel.org>,  Alexander Graf <graf@...zon.com>,
  Mike Rapoport <rppt@...nel.org>,  Pasha Tatashin
 <pasha.tatashin@...een.com>,  linux-kernel@...r.kernel.org,
  kexec@...ts.infradead.org,  linux-mm@...ck.org,  usamaarif642@...il.com,
  rmikey@...a.com,  clm@...com,  riel@...riel.com,  kernel-team@...a.com
Subject: Re: [PATCH v2 2/2] kexec: history: track kexec boot counter

On Tue, Jan 06 2026, Breno Leitao wrote:

> On Fri, Jan 02, 2026 at 09:23:18PM +0100, Pratyush Yadav wrote:
>> On Fri, Jan 02 2026, Breno Leitao wrote:
>> 
>> > Track and display the number of kexec boots since the last cold reboot
>> 
>> Nit: this does not track kexec boots, it tracks KHO boots. None of this
>> can work on normal kexec boots. Can you please update the wording to
>> make that clear?
>> 
>> > when CONFIG_KEXEC_HISTORY is enabled.
>> >
>> > This extends the previous kernel release tracking feature by adding
>> > a counter that increments with each kexec boot. The counter provides
>> > visibility into the kexec chain depth, which is useful for understanding
>> > boot history in production environments.
>> >
>> > Add a new property, "kexec-count" in KHO FDT alongside the existing
>> > "previous-release" property. The counter is:
>> >
>> >  - Initialized to 0 when kho_in is instantiated.
>> >  - Incremented by 1 on each subsequent kexec.
>> >  - Printed alongside the previous kernel release version.
>> >
>> > The counter is stored as a 32-bit unsigned integer in FDT format and is
>> > only active when CONFIG_KEXEC_HISTORY is enabled.
>> 
>> We have such a counter for LUO as well from the properly
>> "liveupdate-number". If you're using LUO, why can't you use that counter
>> directly?
>> 
>> If you're not using LUO, I'm curious, what's your use case? Right now
>> KHO only supports reserve-mem outside of LUO. Is that what you plan to
>> use?
>> 
>> Also, do we want to keep both counters independently? Or do we have one
>> and drop the other? Pasha, what do you think?
>
> In fact, I do not have plan to use LUO right now. My goal is to pass the
> kexec release from kernel to another, and for that I am using KHO to
> pass this information.

Oh, cool. Nice to see other use cases for KHO.

>
> That said, I am planning to use KHO as the infrastructure to pass the
> kernel version from one kernel to another.
>
> Given that I don't think this "feature" should depend on LUO, maybe the
> counters should be independent (?!)

If you aren't using LUO then you certainly can't use its counter. But
LUo users are all KHO users. So perhaps we can get away with removing
the LUO one and moving it to KHO?

-- 
Regards,
Pratyush Yadav