linux-kernel - Re: [PATCH] arm64: Add kernel parameter to disable trap EL0 accesses to IMPDEF regs

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: <86ecqwwig3.wl-maz@kernel.org>
Date: Tue, 21 Oct 2025 13:25:00 +0100
From: Marc Zyngier <maz@...nel.org>
To: Liao Chang <liaochang1@...wei.com>
Cc: <corbet@....net>,
	<catalin.marinas@....com>,
	<will@...nel.org>,
	<akpm@...ux-foundation.org>,
	<paulmck@...nel.org>,
	<pawan.kumar.gupta@...ux.intel.com>,
	<mingo@...nel.org>,
	<bp@...en8.de>,
	<kees@...nel.org>,
	<arnd@...db.de>,
	<fvdl@...gle.com>,
	<broonie@...nel.org>,
	<oliver.upton@...ux.dev>,
	<yeoreum.yun@....com>,
	<yangyicong@...ilicon.com>,
	<james.morse@....com>,
	<ardb@...nel.org>,
	<hardevsinh.palaniya@...iconsignals.io>,
	<linux-doc@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>,
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH] arm64: Add kernel parameter to disable trap EL0 accesses to IMPDEF regs

On Tue, 21 Oct 2025 12:54:28 +0100,
Liao Chang <liaochang1@...wei.com> wrote:
> 
> Add kernel parameter to allow system-wide EL0 access to IMPDEF system
> regregisters and instructions without trapping to EL1/EL2. Since trap
> overhead will compromises benefits, and it's even worse in
> virtualization on CPU where certain IMPDEF registers and instructions
> are designed for EL0 performance use.

Since you mention virtualisation, I want to be clear: there is no way
I will consider anything like this for KVM. KVM will always trap and
UNDEF such register accesses, no matter where they come from (EL0 or
EL1).

Allowing such registers to be accessed from within a guest would make
it impossible to context-switch or save/restore the guest correctly.

You can of course do what you want in your downstream kernel or your
own hypervisor, but I wanted to set the expectations on the upstream
side.

	M.

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