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: <86v7jftjq5.wl-maz@kernel.org>
Date: Wed, 12 Nov 2025 14:21:22 +0000
From: Marc Zyngier <maz@...nel.org>
To: Breno Leitao <leitao@...ian.org>
Cc: catalin.marinas@....com,
	will@...nel.org,
	mark.rutland@....com,
	paulmck@...nel.org,
	mhiramat@...nel.org,
	linux-arm-kernel@...ts.infradead.org,
	linux-kernel@...r.kernel.org,
	kernel-team@...a.com
Subject: Re: arm64: pseudo NMI bootconfig question

On Wed, 12 Nov 2025 14:05:43 +0000,
Breno Leitao <leitao@...ian.org> wrote:
> 
> Hello,
> 
> In most major Linux distributions, it’s common to have a separate debug kernel
> build. This variant is compiled with additional debug configuration options to
> provide deeper observability and easier debugging, typically at the expense of
> some performance.
> 
> This approach is also used in several companies, including mine. The debug
> flavor is usually a drop-in replacement deployed when investigating
> issues, allowing quicker identification before more detailed manual
> debugging.
> 
> I’m currently debugging some hung tasks using the debug kernel flavor and
> noticed that backtraces weren’t printed correctly because PSEUDO NMI isn’t
> enabled.
> 
> AFAIK, to enable PSEUDO NMI on ARM, the following are required:
> 
>  cmdline: irqchip.gicv3_pseudo_nmi=1
>  config: CONFIG_ARM64_PSEUDO_NMI=y
> 
> I wanted to have pseudo NMI enabled by default in the debug kernel
> (without relying on kernel command-line parameters), but this isn’t
> possible today. The reason is that `irqchip.gicv3_pseudo_nmi` is an early
> parameter, which can’t be set through bootconfig, so, independent of my
> .config, I need to hack cmdline arguments to have the debuggability
> I need.
> 
> Question:
> 
> Would it make sense to provide an option to enable pseudo NMI in certain
> kernel configuration without requiring an extra command-line parameter?

[I wasn't asked, but I'll give my answer anyway]

The short answer is no. The long answer is that there is so much
broken HW out there that dies a painful death when enabling pseudo-NMI
that is isn't practical to do so. It also brings a measurable
overhead to some of the most frequent operations (interrupt masking).

Until someone weeds out the broken machines (in some cases, by prying
them from my cold dead hands), the requirement for the option is
likely to stick.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ