[Bug]: Several Issues with respect to alignment for RISC-V assembly routines

[EAlexJ]

Contact Details

alex@minres.com

Version

5.9.1 (commit 6a3eb6f)

Description

RISC-V systems may, but do not need to support unaligned loads and stores. Concretely, there are systems that expect sw / lw and sd / ld to be 4 and 8 byte aligned, respectively. Misaligned loads and stores can then raise an exception.

I ran into a few occasions where alignment was not given.

The first issue I ran into was that there are no alignment requirements for the secret and masterSecret byte Arrays in the Arrays struct. These happened to lay at 1 byte alignment for me and were propagated to some RISC-V assembly, which expected 4 or 8 byte alignment.
I managed to work around this locally by enabling WOLFSSL_USE_ALIGN and prepending the corresponding define:

<internal.h>
typedef struct Arrays {
...
#ifdef WOLFSSL_TLS13
    ALIGN8 byte            secret[SECRET_LEN];
#endif
#ifdef HAVE_KEYING_MATERIAL
    byte            exporterSecret[WC_MAX_DIGEST_SIZE];
#endif
    ALIGN8 byte            masterSecret[SECRET_LEN];
...
} Arrays;

The one I cannot solve on my own is from the following call stack (breakpoint on the faulting instruction):

In this very case createSigData propagates an address in ret = GetMsgHash(ssl, &sigData[idx]); with idx equal to 92. sigData is 4 byte aligned, an offset of 92 is then only 2 byte aligned. This then faults when it propagates the call stack down to this store instruction.

I have tested the standalone wolfcrypt API for RISC-V assembly successfully, but I encounter these issues in the TLS1.3 application I am trying to run. My application runs fine when not enabling the RISC-V assembly.

This is not an exhaustive list but shows what I encountered so far, basically stepping through the build-up of the TLS connection. I encountered the first error when keys were generated, the second one when validating certificates.

Let me know what more I can provide to help you get this resolved.

-Alex

[SparkiDev]

Hi @EAlexJ,

I've made some changes to support chips that don't support unaligned access in PR: #10530
You will need to define WOLFSSL_RISCV_ASM_NO_UNALIGNED to get the alternative assembly code.
I've applied this change everywhere I think there is going to be unaligned memory being used.

Let me know if this works as an alternative.

Thanks,
Sean

[EAlexJ]

I have confirmed that using WOLFSSL_RISCV_ASM_NO_UNALIGNED and the commit you made in the PR solves the issue for the 64-bit version.
However, updating wolfssl to the newest version now introduced a misalignment issue when running my application with RV32.

I will look into it and report what I find
EDIT: The error stems from GMULT. I do not know why WC_32BIT_CPU was not set implicitly before and why this error only now occurs.

[SparkiDev]

Hi @EAlexJ,

What is your configuration line when building for RISC-V 32-bit?

Thanks,
Sean

[SparkiDev]

Hi @EAlexJ,

I've updated the macros to support either using one instruction or multiple when unaligned operations not supported.

Sean

[EAlexJ]

I found the reason, I started using GCM_TABLE in combination with HAVE_AESGCM. Removing the option also removes the misalignment error.

My flags are the following:
./configure flags: --host=riscv64-unknown-elf --enable-debug --enable-debug-code-points --enable-debug-trace-errcodes --enable-usersettings --disable-benchmark --disable-examples --disable-crypttests --disable-threadlocal --disable-asyncthreads --prefix=/<...> host_alias=riscv64-unknown-elf 'CFLAGS= -march=rv32imac_zicsr_zifencei -mabi=ilp32 -mcmodel=medany <link directories> -g

EDIT: Turns out WOLFSSL_RISCV_ASM requires GCM_TABLE, but RV32 does not work with GCM_TABLE

[SparkiDev]

Hi @EAlexJ

Let me know if there are any more issues with the code after my last update.

Thanks,
Sean

[EAlexJ]

Hi Sean,
looks good, however I did not get to try it out yet.

[SparkiDev]

We are going to do a release soon.
I will mark the PR for review.

Sean