linux-kernel - Re: [PATCH v2 1/2] RISC-V: hwprobe: Add MISALIGNED

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: <20240626-aide-nickname-1ef5fef000fb@spud>
Date: Wed, 26 Jun 2024 15:36:35 +0100
From: Conor Dooley <conor@...nel.org>
To: Evan Green <evan@...osinc.com>
Cc: Palmer Dabbelt <palmer@...belt.com>, Yangyu Chen <cyy@...self.name>,
	Charlie Jenkins <charlie@...osinc.com>,
	Andrew Jones <ajones@...tanamicro.com>,
	Albert Ou <aou@...s.berkeley.edu>, Andy Chiu <andy.chiu@...ive.com>,
	Clément Léger <cleger@...osinc.com>,
	Conor Dooley <conor.dooley@...rochip.com>,
	Costa Shulyupin <costa.shul@...hat.com>,
	Jonathan Corbet <corbet@....net>,
	Paul Walmsley <paul.walmsley@...ive.com>, linux-doc@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-riscv@...ts.infradead.org
Subject: Re: [PATCH v2 1/2] RISC-V: hwprobe: Add MISALIGNED_PERF key

On Tue, Jun 25, 2024 at 09:51:20AM -0700, Evan Green wrote:
> RISCV_HWPROBE_KEY_CPUPERF_0 was mistakenly flagged as a bitmask in
> hwprobe_key_is_bitmask(), when in reality it was an enum value. This
> causes problems when used in conjunction with RISCV_HWPROBE_WHICH_CPUS,
> since SLOW, FAST, and EMULATED have values whose bits overlap with
> each other. If the caller asked for the set of CPUs that was SLOW or
> EMULATED, the returned set would also include CPUs that were FAST.
> 
> Introduce a new hwprobe key, RISCV_HWPROBE_KEY_MISALIGNED_PERF, which
> returns the same values in response to a direct query (with no flags),
> but is properly handled as an enumerated value. As a result, SLOW,
> FAST, and EMULATED are all correctly treated as distinct values under
> the new key when queried with the WHICH_CPUS flag.
> 
> Leave the old key in place to avoid disturbing applications which may
> have already come to rely on the key, with or without its broken
> behavior with respect to the WHICH_CPUS flag.
> 
> Fixes: e178bf146e4b ("RISC-V: hwprobe: Introduce which-cpus flag")
> Signed-off-by: Evan Green <evan@...osinc.com>
> Reviewed-by: Charlie Jenkins <charlie@...osinc.com>
> Reviewed-by: Andrew Jones <ajones@...tanamicro.com>
> 
> ---
> 
> Changes in v2:
>  - Clarified the distinction of slow and fast refers to misaligned word
>    accesses. Previously it just said misaligned accesses, leaving it
>    ambiguous as to which type of access was measured.

I think if we are gonna be specific, we should be exactly specific as to
what we have tested and say 32-bit if that's what we're probing/testing
with. That'd be consistent with jesse's proposed wording for vector.

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)