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: <864iuja70l.wl-maz@kernel.org>
Date: Thu, 07 Aug 2025 09:08:26 +0100
From: Marc Zyngier <maz@...nel.org>
To: Palmer Dabbelt <palmer@...belt.com>
Cc: Catalin Marinas <catalin.marinas@....com>,
	Mark Rutland <mark.rutland@....com>,
	Will Deacon <will@...nel.org>,
	oliver.upton@...ux.dev,
	james.morse@....com,
	cohuck@...hat.com,
	anshuman.khandual@....com,
	palmerdabbelt@...a.com,
	lpieralisi@...nel.org,
	kevin.brodsky@....com,
	scott@...amperecomputing.com,
	broonie@...nel.org,
	james.clark@...aro.org,
	yeoreum.yun@....com,
	joey.gouly@....com,
	huangxiaojia2@...wei.com,
	yebin10@...wei.com,
	linux-arm-kernel@...ts.infradead.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] arm64: Expose CPUECTLR{,2}_EL1 via sysfs

On Wed, 06 Aug 2025 20:48:13 +0100,
Palmer Dabbelt <palmer@...belt.com> wrote:
> 
> From: Palmer Dabbelt <palmerdabbelt@...a.com>
> 
> We've found that some of our workloads run faster when some of these
> fields are set to non-default values on some of the systems we're trying
> to run those workloads on.  This allows us to set those values via
> sysfs, so we can do workload/system-specific tuning.
> 
> Signed-off-by: Palmer Dabbelt <palmerdabbelt@...a.com>
> ---
> I've only really smoke tested this, but I figured I'd send it along because I'm
> not sure if this is even a sane thing to be doing -- these extended control
> registers have some wacky stuff in them, so maybe they're not exposed to
> userspace on purpose.  IIUC firmware can gate these writes, though, so it
> should be possible for vendors to forbid the really scary values.

That's really wrong.

For a start, these encodings fall into the IMPDEF range. They won't
exist on non-ARM implementations.

Next, this will catch fire as a guest, either because the hypervisor
will simply refuse to entertain letting it access registers that have
no definition, or because the VM has been migrated from one
implementation to another, and you have no idea this is doing on the
new target.

> 
> That said, we do see some performance improvements here on real workloads.  So
> we're hoping to roll some of this tuning work out more widely, but we also
> don't want to adopt some internal interface.  Thus it'd make our lives easier
> if we could twiddle these bits in a standard way.

Honestly, this is the sort of bring-up stuff that is better kept in
your private sandbox, and doesn't really help in general.

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