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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CAAhSdy2tjOE5aajzydFs8A_drHdBSbWrYTX3CX4e7B6Rm107Bw@mail.gmail.com>
Date: Mon, 10 Feb 2025 15:46:46 +0530
From: Anup Patel <anup@...infault.org>
To: Charlie Jenkins <charlie@...osinc.com>
Cc: Andrew Jones <ajones@...tanamicro.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 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.

>
> 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.

Regards,
Anup