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

[Vivian Wang <wangruikang@iscas.ac.cn>]

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