Add riscv64 support

[rota1001]

This PR did the following things:

• Add riscv64 support by reusing aarch64 syscall table
• Correct aarch64 syscall name and those non-lagacy syscalls marked as lagacy
• Disable link time relaxation to reduce link time (of riscv64) to several seconds
• Fetch the correct rootfs in the build script
• Successfully run kbox on alpine Linux running on the QEMU virt machine

According to the kernel document[1], syscalls are specified in arch/*/kernel/Makefile.syscalls and scripts/syscall.tbl.

It is found that all the aarch64 host syscalls used in kbox has either common, 64 or rlimit tag in scripts/syscall.tbl[2], which means riscv64 share the same host syscall table.

Also, there are two errors found in the host syscall table. (Also according to scripts/syscall.tbl[2]):

• rt_sigalstack is not the correct syscall name, it is sigalstack instead
• getrlimit and statfs are not lagacy syscalls

The build script of rootfs is updated, so the following command can produce a usable alpine.ext4:

$ make ARCH=riscv64 CC=riscv64-linux-gnu-gcc rootfs

For the fetch-lkl.sh script, the riscv64 support is added. However, the pre-built lkl binary has to be updated on GitHub (The github action has to be updated), so for now, it can only be compiled by explicitly assigning the LKL path in the config. The LKL build process is as follows (on x86-64 ubuntu 24.04):

$ sudo dpkg --add-architecture riscv64
$ sudo apt update
$ sudo apt install -y libfuse3-dev:riscv64 libarchive-dev:riscv64
$ git clone --depth 1 https://github.com/lkl/linux.git lkl
$ cd lkl
$ make CROSS_COMPILE=riscv64-linux-gnu- -C tools/lkl

With the LKL path set in the config, the following command can successfully build the kbox:

$ make ARCH=riscv64 CC=riscv64-linux-gnu-gcc

The compiled kbox is successfully run on QEMU and execute /bin/sh.[3]

[1] https://docs.kernel.org/process/adding-syscalls.html#since-6-11
[2] https://github.com/torvalds/linux/blob/master/scripts/syscall.tbl
[3] https://hackmd.io/@rota1001/kbox-rv64#Run-it-on-riscv64

---

Summary by cubic

Adds riscv64 support by reusing the aarch64 host syscall table and updating build scripts for the correct Alpine rootfs. Also fixes host syscall table errors and speeds up riscv64 linking.

• New Features

  • riscv64 support: reuse HOST_NRS_AARCH64; apply seccomp filter for riscv64; add audit arch 0xc00000f3.
  • Build: add riscv64 to fetch-lkl.sh and mkrootfs.sh; include Alpine riscv64 SHA256; disable link-time relaxation with -Wl,--no-relax.
  • Docs: list riscv64 as a supported architecture in README.

• Bug Fixes

  • Use sigaltstack (not rt_sigaltstack) in dispatch and host syscall tables.
  • Correct aarch64 syscall numbers: getrlimit=163, statfs=43.

^{Written for commit d8d82b1. Summary will update on new commits.}

[jserv]

#21 concerns the system call overhead in kbox, which has been observed to be as high as 33× compared to native (bare-metal) execution. Addressing this overhead is a prerequisite for improving overall system performance.

To this end, I plan to prioritize closing #21 by exploring a solution based on binary rewriting. Given current infrastructure constraints and to ensure efficient validation, the initial implementation will focus on x86-64 and arm64 architectures, both of which are fully supported by the machines provided through GitHub Actions.

After the proposed solution has been thoroughly implemented and validated on these architectures, we can proceed to extend support to RISC-V.

[visitorckw]

Looks like unrelated style changes?
Please keep the changes to a minimum.
Otherwise, this will make git blame messy.

[rota1001]

This change was made because the source code wasn't properly formatted with clang-format, which caused it to be blocked by the new commit-hook. Did you mean I have to separate it to another commit?

[visitorckw]

Ideally, a single patch should contain only one logical change.
However, it looks like this patch is doing two things:

1. Fixing a pre-existing clang-format error.
2. Adding RISC-V support.

So, yes, I would prefer splitting this into two patches.

[visitorckw]

Reusing the HOST_NRS_AARCH64 struct directly for RISC-V is semantically confusing for future maintenance. Maybe consider adding a preparatory refactoring patch to rename it to something more generic before wiring up RISC-V support?