linux-kernel - Re: [PATCH] lib/crypto: riscv/chacha: Maintain a frame pointer

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

Message-ID: <c04ad49c-598d-4183-a9dd-00a7883e727a@iscas.ac.cn>
Date: Mon, 1 Dec 2025 09:50:30 +0800
From: Vivian Wang <wangruikang@...as.ac.cn>
To: Eric Biggers <ebiggers@...nel.org>
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] lib/crypto: riscv/chacha: Maintain a frame pointer

On 12/1/25 02:29, Eric Biggers wrote:
> On Sun, Nov 30, 2025 at 06:23:50PM +0800, Vivian Wang wrote:
>> crypto_zvkb doesn't maintain a frame pointer and also uses s0, which
>> means that if it crashes we don't get a stack trace. Modify prologue and
>> epilogue to maintain a frame pointer as -fno-omit-frame-pointer would.
>> Also reallocate registers to match.
>>
>> Signed-off-by: Vivian Wang <wangruikang@...as.ac.cn>
>> ---
>> Found while diagnosing a crypto_zvkb "load address misaligned" crash [1]
>>
>> [1]: https://lore.kernel.org/r/b3cfcdac-0337-4db0-a611-258f2868855f@iscas.ac.cn/
>> ---
>>  lib/crypto/riscv/chacha-riscv64-zvkb.S | 13 ++++++++-----
>>  1 file changed, 8 insertions(+), 5 deletions(-)
> Do I understand correctly that the problem isn't so much that
> crypto_zvkb() doesn't set up its own frame pointer, but rather it reuses
> the frame pointer register (s0 i.e. fp) for other data?
>
> That's what we've seen on other architectures, like x86_64 with %rbp.
> Assembly functions need to set their own frame pointer only if they call
> other functions.  Otherwise, they can just run with their parent's frame
> pointer.  However, in either case, they must not store other data in the
> frame pointer register.
>
> Is that the case on RISC-V too?  If so, the appropriate fix is to just
> stop using s0 for other data; we don't actually need to set up a frame
> pointer.  (Note that none of the RISC-V crypto assembly code sets up
> frame pointers.  So if that was an issue, it would affect every file.)

Thanks for the hint, I can confirm that indeed simply avoiding s0 also
fixes the stack trace problem.

I'll drop the rest of the patch for the next version.

Vivian "dramforever" Wang