linux-kernel - Re: [PATCH v2] lib/crypto: riscv/chacha: Avoid s0/fp register

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] [day] [month] [year] [list]

Message-ID: <20251202063103.GA100366@sol>
Date: Mon, 1 Dec 2025 22:31:03 -0800
From: Eric Biggers <ebiggers@...nel.org>
To: Vivian Wang <wangruikang@...as.ac.cn>
Cc: Jerry Shih <jerry.shih@...ive.com>,
	"Jason A. Donenfeld" <Jason@...c4.com>,
	Ard Biesheuvel <ardb@...nel.org>, Paul Walmsley <pjw@...nel.org>,
	Palmer Dabbelt <palmer@...belt.com>,
	Albert Ou <aou@...s.berkeley.edu>, Alexandre Ghiti <alex@...ti.fr>,
	linux-crypto@...r.kernel.org, linux-riscv@...ts.infradead.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] lib/crypto: riscv/chacha: Avoid s0/fp register

On Tue, Dec 02, 2025 at 02:24:46PM +0800, Vivian Wang wrote:
> On 12/2/25 13:31, Eric Biggers wrote:
> > On Tue, Dec 02, 2025 at 01:25:07PM +0800, Vivian Wang wrote:
> >> In chacha_zvkb, avoid using the s0 register, which is the frame pointer,
> >> by reallocating KEY0 to t5. This makes stack traces available if e.g. a
> >> crash happens in chacha_zvkb.
> >>
> >> No frame pointer maintenence is otherwise required since this is a leaf
> >> function.
> > maintenence => maintenance
> >
> Ouch... I swear I specifically checked this before sending, but
> apparently didn't see this. Thanks for the catch.
> 
> >>  SYM_FUNC_START(chacha_zvkb)
> >>  	addi		sp, sp, -96
> >> -	sd		s0, 0(sp)
> > I know it's annoying, but would you mind also changing the 96 to 88, and
> > decreasing all the offsets by 8, so that we don't leave a hole in the
> > stack where s0 used to be?  Likewise at the end of the function.
> 
> No can do. Stack alignment on RISC-V is 16 bytes, and 80 won't fit.
> 

Hmm, interesting.  It shouldn't actually matter, since this doesn't call
any other function, but we might as well leave it at 96 then.  I don't
think this was considered when any of the RISC-V crypto code was
written, but fortunately this is the only one that uses the stack.

Anyway, I guess I'll apply this as-is then.

- Eric