linux-kernel - Re: [PATCH 7/9] riscv: Prepare for unaligned access type table lookups

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250210-e6a2dfcd7995ffc8a6d918e4@orel>
Date: Mon, 10 Feb 2025 15:06:18 +0100
From: Andrew Jones <ajones@...tanamicro.com>
To: Clément Léger <cleger@...osinc.com>
Cc: Anup Patel <anup@...infault.org>, 
	Charlie Jenkins <charlie@...osinc.com>, linux-riscv@...ts.infradead.org, linux-kernel@...r.kernel.org, 
	paul.walmsley@...ive.com, palmer@...belt.com, jesse@...osinc.com, 
	Anup Patel <apatel@...tanamicro.com>
Subject: Re: [PATCH 7/9] riscv: Prepare for unaligned access type table
 lookups

On Mon, Feb 10, 2025 at 12:07:40PM +0100, Clément Léger wrote:
> 
> 
> On 10/02/2025 11:16, Anup Patel wrote:
> > On Sat, Feb 8, 2025 at 6:53 AM Charlie Jenkins <charlie@...osinc.com> wrote:
> >>
> >> On Fri, Feb 07, 2025 at 05:19:47PM +0100, Andrew Jones wrote:
> >>> Probing unaligned accesses on boot is time consuming. Provide a
> >>> function which will be used to look up the access type in a table
> >>> by id registers. Vendors which provide table entries can then skip
> >>> the probing.
> >>
> >> The access checker in my experience is only time consuming on slow
> >> hardware. Hardware that supports fast unaligned accesses isn't really
> >> impacted by this? Avoiding a list of hardware that has slow/fast
> >> unaligned accesses in the kernel was the main reason for dynamically
> >> checking. We did introduce the config option to compile the kernel with
> >> assumed slow/fast accesses, which of course has the downside of
> >> recompiling the kernel and I assume that you already considered that.
> > 
> > The kconfig option does not align with the vision of running the same
> > kernel image across platforms.
> 
> I'd would be advocating to remove compile time options as well and use
> another way to skip the probe (see below).
> 
> > 
> >>
> >> Instead of having a table in the kernel, something that would be more
> >> platform agnostic would be to have an extension that signals this
> >> information. That seems like it would accomplish the same goal and
> >> leverage the existing infrastructure in the kernel, albeit with the need
> >> to make a new extension.
> >>
> > 
> > IMO, expecting an ISA extension to be defined for all possible
> > microarchitectural choices is not going to scale so it is better
> > to have infrastructure in kernel itself to infer microarchitectural
> > choices based on RISC-V implementation ID.
> 
> Since adding an extension seems quite unlikely, and that a device-tree
> property is likely DT centric and not applicable to ACPI as well, was a
> command line argument considered ?
>

I did consider adding a command line option in addition to the table,
allowing platforms which neither have a table entry [yet] nor want to do
the speed test, to set whatever they like. In the end, I dropped it, since
I don't have a use case at this time. However, if we really don't want a
table, then I can look into the command line option instead.

Thanks,
drew