lib/crypto: riscv: crypto_zvkb crashes on selftest if no misaligned vector support

lib/crypto: riscv: crypto_zvkb crashes on selftest if no misaligned vector support

[Vivian Wang]

Hi,

We ran into a problem with chacha_zvkb, where having:

- OpenSBI 1.7+ (for FWFT support)
- CRYPTO_CHACHA20POLY1305=y and CRYPTO_SELFTESTS=y (and deps, of course)
- Hardware with Zvkb support
- Hardware *without* misaligned vector load/store support

Leads to a crash on boot during selftest on a vlsseg8e32.v instruction,
because it requires 4-byte alignment of the buffers.

OpenSBI by default emulates vector misaligned operations, however Linux
explicitly disables it with SBI FWFT while not providing vector
misaligned emulation of its own.

This can be reproduced by running everything in Spike without
--misaligned, and is reproducible on stable 6.17.9, 6.18-rc1 and
6.18-rc7. See log at the end. Note that I had to fix chacha_zvkb
somewhat to have it retain a frame pointer to get a stack trace - patch
will be sent later.

Setting cra_alignmask to 3 for everything in crypto/chacha.c "fixes"
this, but there seems to be no obvious way to say "if use_zvkb then
cra_alignmask = 3", and, not being familiar with the crypto API stuff, I
can't figure out a good way to say "if riscv then cra_alignmask = 3" either.

AFAICT, this problem was missed from the very start since commit
bb54668837a0 ("crypto: riscv - add vector crypto accelerated ChaCha20").

Please advise.

Thanks,
Vivian "dramforever" Wang

Crash log:

[    0.160370] Oops - load address misaligned [#1]
[    0.160370] Modules linked in:
[    0.160375] CPU: 0 UID: 0 PID: 44 Comm: cryptomgr_test Not tainted 6.18.0-rc1-dirty #5 NONE
[    0.160385] Hardware name: ucbbar,spike-bare (DT)
[    0.160385] epc : chacha_zvkb+0xa4/0x300
[    0.160395]  ra : chacha_crypt+0xe0/0x134
[    0.160400] epc : ffffffff8051eff8 ra : ffffffff8051eee8 sp : ff2000000022b730
[    0.160405]  gp : ffffffff81a1f650 tp : ff600000027d1800 t0 : 000000006b206574
[    0.160410]  t1 : 00000000000000d8 t2 : 0000000000000001 s0 : ff2000000022b790
[    0.160415]  s1 : ffffffffbca3aa27 a0 : ff2000000022b8a8 a1 : ff600000030a8001
[    0.160420]  a2 : ff600000030b8001 a3 : 0000000000000001 a4 : 000000000000000c
[    0.160425]  a5 : 0000000061707865 a6 : 000000003320646e a7 : 0000000079622d32
[    0.160430]  s2 : 000000001a00608f s3 : ffffffff948be502 s4 : 0000000032e565c6
[    0.160440]  s5 : 000000005b7013d5 s6 : ffffffffc159e731 s7 : ffffffff8a5fbd3a
[    0.160445]  s8 : 0000000000000000 s9 : 0000000000000000 s10: ffffffffaf1e2dd8
[    0.160450]  s11: ffffffff9e109452 t3 : 0000000000000040 t4 : ffffffffbca3aa27
[    0.160455]  t5 : 00000000294d72a5 t6 : ffffffff948be502
[    0.160460] status: 8000000200000720 badaddr: ff600000030a8001 cause: 0000000000000004
[    0.160465] [<ffffffff8051eff8>] chacha_zvkb+0xa4/0x300
[    0.160470] [<ffffffff8051eee8>] chacha_crypt+0xe0/0x134
[    0.160480] [<ffffffff804ab952>] chacha_stream_xor+0x192/0x1cc
[    0.160485] [<ffffffff804abbc6>] crypto_xchacha_crypt+0x1ca/0x1f0
[    0.160495] [<ffffffff8049ea84>] crypto_skcipher_encrypt+0x28/0x44
[    0.160505] [<ffffffff804a7bde>] test_skcipher_vec_cfg+0x266/0x5d8
[    0.160515] [<ffffffff804a7fcc>] test_skcipher+0x7c/0xf4
[    0.160530] [<ffffffff804a80b8>] alg_test_skcipher+0x74/0x16c
[    0.160540] [<ffffffff804a8c08>] alg_test+0xe4/0x49c
[    0.160545] [<ffffffff804a53b8>] cryptomgr_test+0x1c/0x3c
[    0.160555] [<ffffffff8004dff4>] kthread+0xc0/0x178
[    0.160565] [<ffffffff80012306>] ret_from_fork_kernel+0xe/0xcc
[    0.160580] [<ffffffff80b61bbe>] ret_from_fork_kernel_asm+0x16/0x18
[    0.160595] Code: a657 5208 4657 02cc c6d7 5e0c 4757 5e0d c7d7 5e0d (e807) ebc5
[    0.160600] ---[ end trace 0000000000000000 ]---
[    0.160605] Kernel panic - not syncing: Fatal exception in interrupt
[    0.161415] ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]---

Re: lib/crypto: riscv: crypto_zvkb crashes on selftest if no misaligned vector support

[Ard Biesheuvel]

On Sun, 30 Nov 2025 at 10:13, Vivian Wang <wangruikang@iscas.ac.cn> wrote:
>
> Hi,
>
> We ran into a problem with chacha_zvkb, where having:
>
> - OpenSBI 1.7+ (for FWFT support)
> - CRYPTO_CHACHA20POLY1305=y and CRYPTO_SELFTESTS=y (and deps, of course)
> - Hardware with Zvkb support
> - Hardware *without* misaligned vector load/store support
>
> Leads to a crash on boot during selftest on a vlsseg8e32.v instruction,
> because it requires 4-byte alignment of the buffers.
>
> OpenSBI by default emulates vector misaligned operations, however Linux
> explicitly disables it with SBI FWFT while not providing vector
> misaligned emulation of its own.
>
> This can be reproduced by running everything in Spike without
> --misaligned, and is reproducible on stable 6.17.9, 6.18-rc1 and
> 6.18-rc7. See log at the end. Note that I had to fix chacha_zvkb
> somewhat to have it retain a frame pointer to get a stack trace - patch
> will be sent later.
>
> Setting cra_alignmask to 3 for everything in crypto/chacha.c "fixes"
> this, but there seems to be no obvious way to say "if use_zvkb then
> cra_alignmask = 3", and, not being familiar with the crypto API stuff, I
> can't figure out a good way to say "if riscv then cra_alignmask = 3" either.
>
> AFAICT, this problem was missed from the very start since commit
> bb54668837a0 ("crypto: riscv - add vector crypto accelerated ChaCha20").
>
> Please advise.
>

I'd suggest to only enable this version of the code if both Zicclsm
and Zvkb are supported (assuming that Zicclsm is the extension that
would result in these misaligned accesses to be permitted).

Playing with the cra_alignmask is likely insufficient, because it does
not fix the use cases that call the library interface directly.

Re: lib/crypto: riscv: crypto_zvkb crashes on selftest if no misaligned vector support

[Eric Biggers]

On Sun, Nov 30, 2025 at 11:59:58AM +0100, Ard Biesheuvel wrote:
> On Sun, 30 Nov 2025 at 10:13, Vivian Wang <wangruikang@iscas.ac.cn> wrote:
> >
> > Hi,
> >
> > We ran into a problem with chacha_zvkb, where having:
> >
> > - OpenSBI 1.7+ (for FWFT support)
> > - CRYPTO_CHACHA20POLY1305=y and CRYPTO_SELFTESTS=y (and deps, of course)
> > - Hardware with Zvkb support
> > - Hardware *without* misaligned vector load/store support
> >
> > Leads to a crash on boot during selftest on a vlsseg8e32.v instruction,
> > because it requires 4-byte alignment of the buffers.
> >
> > OpenSBI by default emulates vector misaligned operations, however Linux
> > explicitly disables it with SBI FWFT while not providing vector
> > misaligned emulation of its own.
> >
> > This can be reproduced by running everything in Spike without
> > --misaligned, and is reproducible on stable 6.17.9, 6.18-rc1 and
> > 6.18-rc7. See log at the end. Note that I had to fix chacha_zvkb
> > somewhat to have it retain a frame pointer to get a stack trace - patch
> > will be sent later.
> >
> > Setting cra_alignmask to 3 for everything in crypto/chacha.c "fixes"
> > this, but there seems to be no obvious way to say "if use_zvkb then
> > cra_alignmask = 3", and, not being familiar with the crypto API stuff, I
> > can't figure out a good way to say "if riscv then cra_alignmask = 3" either.
> >
> > AFAICT, this problem was missed from the very start since commit
> > bb54668837a0 ("crypto: riscv - add vector crypto accelerated ChaCha20").
> >
> > Please advise.
> >
> 
> I'd suggest to only enable this version of the code if both Zicclsm
> and Zvkb are supported (assuming that Zicclsm is the extension that
> would result in these misaligned accesses to be permitted).
> 
> Playing with the cra_alignmask is likely insufficient, because it does
> not fix the use cases that call the library interface directly.

Yes, we should make all the RISC-V vector crypto code (i.e., anything in
lib/crypto/riscv/ and arch/riscv/crypto/ that uses vector instructions)
be enabled only when the CPU supports fast misaligned vector accesses.
That was the original intent, but it seems the check never actually made
it into the code because it predated the core RISC-V support for
detecting that capability.

That support later got added by the following commit:

    commit e7c9d66e313bc0f7cb185c4972c3c9383a0da70f
    Author: Jesse Taube <jesse@rivosinc.com>
    Date:   Thu Oct 17 12:00:22 2024 -0700

        RISC-V: Report vector unaligned access speed hwprobe

Note that Zicclsm is supposedly not the correct thing to check.  See
https://lore.kernel.org/linux-riscv/20231122-displace-reformat-9ca68c3dc66c@spud/

It looks like all the RISC-V crypto code needs to check for
this_cpu_read(vector_misaligned_access) ==
RISCV_HWPROBE_MISALIGNED_VECTOR_FAST.
But it may be in need of a helper function.

Any volunteers?  Again, many files need this, not just the ChaCha code.

- Eric

Re: lib/crypto: riscv: crypto_zvkb crashes on selftest if no misaligned vector support

[Eric Biggers]

On Sun, Nov 30, 2025 at 10:43:41AM -0800, Eric Biggers wrote:
> On Sun, Nov 30, 2025 at 11:59:58AM +0100, Ard Biesheuvel wrote:
> > On Sun, 30 Nov 2025 at 10:13, Vivian Wang <wangruikang@iscas.ac.cn> wrote:
> > >
> > > Hi,
> > >
> > > We ran into a problem with chacha_zvkb, where having:
> > >
> > > - OpenSBI 1.7+ (for FWFT support)
> > > - CRYPTO_CHACHA20POLY1305=y and CRYPTO_SELFTESTS=y (and deps, of course)
> > > - Hardware with Zvkb support
> > > - Hardware *without* misaligned vector load/store support
> > >
> > > Leads to a crash on boot during selftest on a vlsseg8e32.v instruction,
> > > because it requires 4-byte alignment of the buffers.
> > >
> > > OpenSBI by default emulates vector misaligned operations, however Linux
> > > explicitly disables it with SBI FWFT while not providing vector
> > > misaligned emulation of its own.
> > >
> > > This can be reproduced by running everything in Spike without
> > > --misaligned, and is reproducible on stable 6.17.9, 6.18-rc1 and
> > > 6.18-rc7. See log at the end. Note that I had to fix chacha_zvkb
> > > somewhat to have it retain a frame pointer to get a stack trace - patch
> > > will be sent later.
> > >
> > > Setting cra_alignmask to 3 for everything in crypto/chacha.c "fixes"
> > > this, but there seems to be no obvious way to say "if use_zvkb then
> > > cra_alignmask = 3", and, not being familiar with the crypto API stuff, I
> > > can't figure out a good way to say "if riscv then cra_alignmask = 3" either.
> > >
> > > AFAICT, this problem was missed from the very start since commit
> > > bb54668837a0 ("crypto: riscv - add vector crypto accelerated ChaCha20").
> > >
> > > Please advise.
> > >
> > 
> > I'd suggest to only enable this version of the code if both Zicclsm
> > and Zvkb are supported (assuming that Zicclsm is the extension that
> > would result in these misaligned accesses to be permitted).
> > 
> > Playing with the cra_alignmask is likely insufficient, because it does
> > not fix the use cases that call the library interface directly.
> 
> Yes, we should make all the RISC-V vector crypto code (i.e., anything in
> lib/crypto/riscv/ and arch/riscv/crypto/ that uses vector instructions)
> be enabled only when the CPU supports fast misaligned vector accesses.
> That was the original intent, but it seems the check never actually made
> it into the code because it predated the core RISC-V support for
> detecting that capability.
> 
> That support later got added by the following commit:
> 
>     commit e7c9d66e313bc0f7cb185c4972c3c9383a0da70f
>     Author: Jesse Taube <jesse@rivosinc.com>
>     Date:   Thu Oct 17 12:00:22 2024 -0700
> 
>         RISC-V: Report vector unaligned access speed hwprobe
> 
> Note that Zicclsm is supposedly not the correct thing to check.  See
> https://lore.kernel.org/linux-riscv/20231122-displace-reformat-9ca68c3dc66c@spud/
> 
> It looks like all the RISC-V crypto code needs to check for
> this_cpu_read(vector_misaligned_access) ==
> RISCV_HWPROBE_MISALIGNED_VECTOR_FAST.
> But it may be in need of a helper function.
> 
> Any volunteers?  Again, many files need this, not just the ChaCha code.

Looking into this a bit more, on RISC-V the kernel actually checks and
records the vector misaligned access speed on each online CPU.  So not
only is RISC-V fragmented in whether this is supported in general, but
it can also be fragmented between different CPUs on the same system.

This means that the status of whether vector misaligned accesses are
supported and fast can change as CPUs go online and offline.

Indeed, there's already a corresponding static key for scalar misaligned
accesses that gets turned on and off as CPUs go online and offline.

But there's none for vector.  And this approach seems fundamentally
broken anyway, as it means that support for misaligned accesses can get
pulled out from underneath users.

I think we'll just need to make the RISC-V crypto code conditional on
CONFIG_RISCV_EFFICIENT_VECTOR_UNALIGNED_ACCESS=y.  Having this info be
statically known, like it is on the other architectures, is the only
reasonable way to do it.

- Eric