All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: Vivian Wang <wangruikang@iscas.ac.cn>
Cc: Jerry Shih <jerry.shih@sifive.com>,
	"Jason A. Donenfeld" <Jason@zx2c4.com>,
	Ard Biesheuvel <ardb@kernel.org>, Paul Walmsley <pjw@kernel.org>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Alexandre Ghiti <alex@ghiti.fr>,
	linux-crypto@vger.kernel.org, linux-riscv@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] lib/crypto: riscv/chacha: Avoid s0/fp register
Date: Mon, 1 Dec 2025 22:31:03 -0800	[thread overview]
Message-ID: <20251202063103.GA100366@sol> (raw)
In-Reply-To: <80cb6553-af8f-4fce-a010-dff3a33c3779@iscas.ac.cn>

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

WARNING: multiple messages have this Message-ID (diff)
From: Eric Biggers <ebiggers@kernel.org>
To: Vivian Wang <wangruikang@iscas.ac.cn>
Cc: Jerry Shih <jerry.shih@sifive.com>,
	"Jason A. Donenfeld" <Jason@zx2c4.com>,
	Ard Biesheuvel <ardb@kernel.org>, Paul Walmsley <pjw@kernel.org>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Alexandre Ghiti <alex@ghiti.fr>,
	linux-crypto@vger.kernel.org, linux-riscv@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] lib/crypto: riscv/chacha: Avoid s0/fp register
Date: Mon, 1 Dec 2025 22:31:03 -0800	[thread overview]
Message-ID: <20251202063103.GA100366@sol> (raw)
In-Reply-To: <80cb6553-af8f-4fce-a010-dff3a33c3779@iscas.ac.cn>

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

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

  reply	other threads:[~2025-12-02  6:32 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-02  5:25 [PATCH v2] lib/crypto: riscv/chacha: Avoid s0/fp register Vivian Wang
2025-12-02  5:25 ` Vivian Wang
2025-12-02  5:31 ` Eric Biggers
2025-12-02  5:31   ` Eric Biggers
2025-12-02  6:24   ` Vivian Wang
2025-12-02  6:24     ` Vivian Wang
2025-12-02  6:31     ` Eric Biggers [this message]
2025-12-02  6:31       ` Eric Biggers
2025-12-09  3:58       ` Jerry Shih
2025-12-09  3:58         ` Jerry Shih
2025-12-09  5:23         ` Samuel Holland
2025-12-09  5:23           ` Samuel Holland
2025-12-08 23:09 ` Eric Biggers
2025-12-08 23:09   ` Eric Biggers
2025-12-19  8:10 ` patchwork-bot+linux-riscv
2025-12-19  8:10   ` patchwork-bot+linux-riscv

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20251202063103.GA100366@sol \
    --to=ebiggers@kernel.org \
    --cc=Jason@zx2c4.com \
    --cc=alex@ghiti.fr \
    --cc=aou@eecs.berkeley.edu \
    --cc=ardb@kernel.org \
    --cc=jerry.shih@sifive.com \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=palmer@dabbelt.com \
    --cc=pjw@kernel.org \
    --cc=wangruikang@iscas.ac.cn \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.