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: <wqzhgeu5vlkeuomajvy7vf3x4gf3fsnzmczmkswvjo7xdyzzbo@6uqjqftbzgot>
Date: Thu, 13 Nov 2025 02:37:22 -0800
From: Breno Leitao <leitao@...ian.org>
To: Masami Hiramatsu <mhiramat@...nel.org>, oss@...at.biz
Cc: catalin.marinas@....com, will@...nel.org, mark.rutland@....com, 
	paulmck@...nel.org, linux-arm-kernel@...ts.infradead.org, 
	linux-kernel@...r.kernel.org, kernel-team@...a.com
Subject: Re: arm64: pseudo NMI bootconfig question

Hello Masami,

On Thu, Nov 13, 2025 at 01:34:03PM +0900, Masami Hiramatsu wrote:
> > 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.
> 
> Yeah, that parameter is for early architecture initialization,
> which is done before parsing bootconfig.
> 
> Can you try building kernel with:
> 
> (arm64)
> cmdline=$(cat /proc/cmdline)
> CONFIG_CMDLINE="irqchip.gicv3_pseudo_nmi=1 ${cmdline}"
> CMDLINE_FORCE=y

This option isn’t practical for my use case since I maintain a generic
debug kernel that needs to support multiple workloads and services, each
with their own kernel command line. I’d need something similar to the
old CMDLINE_EXTEND feature (which was removed some time ago), or perhaps
a mechanism like CMDLINE_PREPEND or CMDLINE_APPEND, which were never
introduced.

Another possible solution would be to load bootconfig earlier in the
boot process so that early parameters can be defined within bootconfig.
Petr suggested this approach some time back, but it doesn’t appear to
have made it upstream.

https://lore.kernel.org/all/20231123194106.08f5832f558fe806b1fd8098@kernel.org/

I’m not fully up to speed on the details of this change, so I want to
ask directly: Would Petr’s approach—allowing early parameters to be set
via bootconfig make sense from a bootconfig design perspective?

> BTW I wonder why you can not configure your bootloader to pass it.

The main issue is that changing cmdline parameters increases the
confusion for users, and updating the kernel command line isn’t simple
in a heterogeneous environment.

My objective is to provide a drop-in kernel replacement, so the user
only needs to swap the kernel binary, gaining additional debugging
capabilities without modifying anything else.

Additionally, it’s common for the same kernel version to be used across
different bootloaders, which makes distributing and installing debug
kernels even more complicated if additional changes (such as appending
configurations to the cmdline) are required.

Thanks for your help!
--breno

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ