linux-kernel - Re: [PATCH v5 2/2] riscv: Set unaligned access speed at compile time

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: <20240229-ship-frail-52cd06745fc2@spud>
Date: Thu, 29 Feb 2024 14:47:39 +0000
From: Conor Dooley <conor@...nel.org>
To: Charlie Jenkins <charlie@...osinc.com>
Cc: Paul Walmsley <paul.walmsley@...ive.com>,
	Palmer Dabbelt <palmer@...belt.com>,
	Albert Ou <aou@...s.berkeley.edu>,
	Jisheng Zhang <jszhang@...nel.org>, Evan Green <evan@...osinc.com>,
	Clément Léger <cleger@...osinc.com>,
	Eric Biggers <ebiggers@...nel.org>,
	Elliot Berman <quic_eberman@...cinc.com>,
	Charles Lohr <lohr85@...il.com>,
	Conor Dooley <conor.dooley@...rochip.com>,
	linux-riscv@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v5 2/2] riscv: Set unaligned access speed at compile time

Clement,

On Wed, Feb 28, 2024 at 10:43:20AM +0000, Conor Dooley wrote:
> > @@ -413,7 +411,9 @@ int handle_misaligned_load(struct pt_regs *regs)
> >  
> >  	perf_sw_event(PERF_COUNT_SW_ALIGNMENT_FAULTS, 1, regs, addr);
> >  
> > +#ifdef CONFIG_RISCV_PROBE_UNALIGNED_ACCESS
> 
> if (IS_ENABLED()), no?
> But perhaps more interestingly - why is this being set here at all?
> My understanding of the emulated stuff was that if the in-kernel
> emulation was enabled, it would be used unless the CPU itself supported
> fast accesses.

> I would expect this to be advertised to userspace once
> the system has booted, not set the first time that a cpu emulates an
> access,
> I feel like I need to take a look at how this has been implemented, I
> never really looked too closely at it and how it is enabled does not
> match my expectations.

I did look at this more closely and I understand why this is being done.
In the vast majority of situations I think it is going to work perfectly
fine, since that first access is going to be during the boot time
probing.
.
> >  	*this_cpu_ptr(&misaligned_access_speed) = RISCV_HWPROBE_MISALIGNED_EMULATED;
> > +#endif
> >  
> >  	if (!unaligned_enabled)
> >  		return -1;

This is in the diff, so I am commenting here. Firstly, why does this
return -1 and not a regular negative errno?

Secondly, this looks pretty suspect to me - if the sysctl is used to
disable the emulation things like hwprobe will still report that access
is emulated if during boot it was enabled.
I think that if this condition is hit, we actually need to change the
per-cpu variable to set the alignment to unsupported, given the
emulation will (at present & if my understanding is correct) only be
enabled when there's not underlying support for unaligned accesses.

Thoughts?

Cheers,
Conor.

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