linux-kernel - Re: [PATCH] arm64: Expose CPUECTLR{,2}

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: <mhng-48855B75-93F8-4CE3-B50C-26D49C2F9223@palmerdabbelt-mac>
Date: Thu, 07 Aug 2025 11:14:32 -0700 (PDT)
From: Palmer Dabbelt <palmer@...belt.com>
To: broonie@...nel.org
CC: Marc Zyngier <maz@...nel.org>, 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, 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 Thu, 07 Aug 2025 10:57:26 PDT (-0700), broonie@...nel.org wrote:
> On Thu, Aug 07, 2025 at 10:26:29AM -0700, Palmer Dabbelt wrote:
>> On Thu, 07 Aug 2025 01:08:26 PDT (-0700), Marc Zyngier wrote:
>
>> > For a start, these encodings fall into the IMPDEF range. They won't
>> > exist on non-ARM implementations.
>
>> OK, and that's because it says "Provides additional IMPLEMENTATION DEFINED
>> configuration and control options for the processor." at the start of the
>> manual page?  Sorry, I'm kind of new to trying to read the Arm specs -- I
>> thought just the meaning of the values was changing, but I probably just
>> didn't read enough specs.
>
> Yes, pretty much and also because this is in a range of registers
> reserved for use by the specific implementation.  See DDI0487 (the ARM)
> version L.a sections D23.3.2 and D24.2.162 which specify the
> IMPLEMENTATION DEFINED system register range, and the definition of the
> term IMPLEMENTATION DEFINED in the glossary of DDI0487.  If you see a
> small upper case term like that in a spec related to the architecture
> then it'll have a specific architectural defintion.

Thanks!

>> That said, part of the reason I just sent this as-is is because I was sort
>> of expecting the answer to be "no" here.  No big deal if that's the case, we
>> can figure out some other way to solve the problem.  Happy to throw some
>> time in to making some more generic flavor of this, though...
>
> It's something that does come up, working out a way to make use of the
> tuning in the IMPDEF registers in a way that generic software can safely
> and sensibly make use of is rather non-trivial though.

Ya, I'd expect it to be a bit of a time sink -- even if something like 
this patch had gone in we would have had a pile of ugliness in 
userspace.  I think there's no way around some amount of ugliness when 
it comes to implemnetation-specific, though.

That said, if our nubers do pan out here then we'll likely need to do 
something.  So if a more generic solution is interesting to people then 
I'm happy to throw some time at it, shouldn't be too hard to justify on 
my end.