linux-kernel - Re: [PATCH 2/2] x86/CPU/AMD: Print the reason for the last reset

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: <Z_TLvoBDmCRRy12t@gmail.com>
Date: Tue, 8 Apr 2025 09:09:50 +0200
From: Ingo Molnar <mingo@...nel.org>
To: Borislav Petkov <bp@...en8.de>
Cc: Mario Limonciello <superm1@...nel.org>,
	Jonathan Corbet <corbet@....net>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	Dave Hansen <dave.hansen@...ux.intel.com>,
	"maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" <x86@...nel.org>,
	"H . Peter Anvin" <hpa@...or.com>,
	"open list:DOCUMENTATION" <linux-doc@...r.kernel.org>,
	open list <linux-kernel@...r.kernel.org>,
	Yazen Ghannam <yazen.ghannam@....com>,
	Mario Limonciello <mario.limonciello@....com>
Subject: Re: [PATCH 2/2] x86/CPU/AMD: Print the reason for the last reset

* Borislav Petkov <bp@...en8.de> wrote:

> On Mon, Apr 07, 2025 at 01:56:57PM -0500, Mario Limonciello wrote:
> > Boris, your thoughts please?
> 
> Right, how hard would it be to decode those as much as possible without
> having users go look somewhere first?
> 
> I mean, we can always go look somewhere for more info but for starters we
> should display as much useful information as possible.

Yeah, and I also have an admittedly selfish reason to ask for this: I 
have a Zen 15h system that is at times unreliable and will 
spontaneously reboot, and I'd *love* to see whether this reboot-reason 
register gives me any further insight as to the root cause. :-) 15h 
appears to be the family when this feature was introduced?

Having it printed early straight on bootup in decoded text is very 
useful for another reason as well: if a system is unreliable it might 
not make it to userspace to run any tooling ...

But I think a more structured sysfs entry would be useful as well in 
addition to the bootup printout (for the raw value if nothing else), if 
any sysadmin tooling wants to pick up on this register.

Thanks,

	Ingo