seccomp
RFE: add RISC-V 32-bit arch support
Update syscall.csv to reflect rv32 arch and use latest 5.13-rc5 kernel for that
Coverage increased (+0.01%) to 89.615% when pulling 063724705f6715f9339fd8cbe2eb751f28b3b70d on kraj:riscv32 into a792221492f700f8b2beb5939adfa92de6b7f6f1 on seccomp:main.
I think the changes look really good. Thanks, @kraj.
It looks like we forgot to update this list in arch-syscall-validate when we added RISCV64. (Github won't let me comment on lines that haven't been modified.) We should update it with both RISCV64 and RISCV32.
I don't have access to a RISCV32 box, and obviously our continuous integration isn't setup to run it either. Do the following commands pass on RISCV32:
# ./configure --enable-python # make check # (cd tests; ./regression -T live)
Here is summary on qemu
Regression Test Summary
tests run: 4388
tests skipped: 149
tests passed: 4385
tests failed: 3
tests errored: 86
Failed tests Test 55-basic-pfc_binary_tree%%001-00001 result: FAILURE 55-basic-pfc_binary_tree.sh rc=1
There is a batch of tests which errored with same message like
batch name: 53-sim-binary_tree
test mode: c
test type: bpf-sim
test arch: x86_64
Test 53-sim-binary_tree%%001-00001 result: ERROR 53-sim-binary_tree rc=14
test arch: x86_64
...
batch name: 36-sim-ipc_syscalls
test mode: c
test type: bpf-sim
test arch: x86
Test 36-sim-ipc_syscalls%%001-00001 result: ERROR 36-sim-ipc_syscalls rc=14
...
Does this look ok ? I am no way expert in libseccomp but if you give some hints on fixing these tests I can try Let me know
I also ran tests on my pc and it came all passing
Regression Test Summary
tests run: 7443
tests skipped: 46
tests passed: 7443
tests failed: 0
tests errored: 0
Here is summary on qemu
Thanks!
Failed tests Test 55-basic-pfc_binary_tree%%001-00001 result: FAILURE 55-basic-pfc_binary_tree.sh rc=1
This failure doesn't surprise me. The syscall numbers won't align between RISC-V 32 and x86_64, so that's likely the culprit.
batch name: 53-sim-binary_tree
test mode: c
test type: bpf-sim
test arch: x86_64
Test 53-sim-binary_tree%%001-00001 result: ERROR 53-sim-binary_tree rc=14
test arch: x86_64
This failure is more interesting, but I would be fine with ignoring it for this patchset. (Adding a github issue might be a good idea, though). The first check of test 53 expects a return code of ERRNO(0) - which now that I think about it doesn't really make sense. Looks like RISC-V 32 got EFAULT instead.
batch name: 36-sim-ipc_syscalls
test mode: c
test type: bpf-sim
test arch: x86
Test 36-sim-ipc_syscalls%%001-00001 result: ERROR 36-sim-ipc_syscalls rc=14
This error could be the most concerning. Does RISC-V 32 multiplex its IPC and/or socket syscalls? See here and here for other architecture examples. You may need to look through the RISC-V kernel code to truly verify.
Does this look ok ? I am no way expert in libseccomp but if you give some hints on fixing these tests I can try
Yes, we're definitely getting closer.
Could you please look into the IPC issue? I'll try to create a RISC-V 32 qemu VM. I would prefer to resolve these issues if they aren't too difficult - famous last words :)
Thanks for your help!
@kraj - I was able to run the automated libseccomp tests on a RISC-V 64-bit Fedora qemu image. They all passed :)
I half-heartedly looked around for a 32-bit RISC-V Linux image (from any distro) but didn't find one. What are you running?
One quick comment, please change the subject line on commit ee4aba3f59b4bf52a74cb3917e64c704250de8ef; something like "syscalls: update the syscall defs for Linux v5.13-rc5" or similar. We try very hard to stick to the "<subject_area>:<brief_description>" format.
Thanks.
One quick comment, please change the subject line on commit ee4aba3; something like "syscalls: update the syscall defs for Linux v5.13-rc5" or similar. We try very hard to stick to the "<subject_area>:<brief_description>" format.
Thanks.
done
@kraj - I was able to run the automated libseccomp tests on a RISC-V 64-bit Fedora qemu image. They all passed :)
I half-heartedly looked around for a 32-bit RISC-V Linux image (from any distro) but didn't find one. What are you running?
I am using yocto to build 32bit qemu image. I can upload one for you if you like
I am using yocto to build 32bit qemu image. I can upload one for you if you like
@kraj - That would be awesome. Thanks!
I am using yocto to build 32bit qemu image. I can upload one for you if you like
@kraj - That would be awesome. Thanks!
@drakenclimber I have uploaded needed artifacts into https://uclibc.org/~kraj/qemuriscv32/ there is run.sh script which can help in booting it in qemu. Let me know how it goes.
I'm not sure what's going wrong with my RISC-V 32 qemu setup. (RISC-V 64 worked fine for me.) It's hanging between the hardware output and the first dmesg line from the kernel. I've tried rebuilding a couple different versions of qemu and a couple different kernels.
I'll try and revisit it next week sometime.
I'm not sure what's going wrong with my RISC-V 32 qemu setup. (RISC-V 64 worked fine for me.) It's hanging between the hardware output and the first dmesg line from the kernel. I've tried rebuilding a couple different versions of qemu and a couple different kernels.
I'll try and revisit it next week sometime.
I build qemu also using yocto, but this should have worked with system qemu too from your distro ( fedora/debian) If needed perhaps you can build yocto I can help.
Getting closer. I switched over to using your kernel. (In fact I'm using all of the files you provided verbatim.)
Now it's puking on my rootfs:
[ 1.551081] EXT4-fs (vda): bad geometry: block count 725665 exceeds size of device (695776 blocks)
[ 1.554322] EXT4-fs (vda): bad geometry: block count 725665 exceeds size of device (695776 blocks)
...
[ 1.604849] driver: virtio_blk
[ 1.605066] No filesystem could mount root, tried:
[ 1.605081] ext3
[ 1.605223] ext2
[ 1.605282] ext4
[ 1.605339] btrfs
[ 1.605399]
[ 1.605765] VFS: Unable to mount root fs on unknown-block(253,0)
[ 1.606136] User configuration error - no valid root filesystem found
Getting closer. I switched over to using your kernel. (In fact I'm using all of the files you provided verbatim.)
Now it's puking on my rootfs:
[ 1.551081] EXT4-fs (vda): bad geometry: block count 725665 exceeds size of device (695776 blocks) [ 1.554322] EXT4-fs (vda): bad geometry: block count 725665 exceeds size of device (695776 blocks) ... [ 1.604849] driver: virtio_blk [ 1.605066] No filesystem could mount root, tried: [ 1.605081] ext3 [ 1.605223] ext2 [ 1.605282] ext4 [ 1.605339] btrfs [ 1.605399] [ 1.605765] VFS: Unable to mount root fs on unknown-block(253,0) [ 1.606136] User configuration error - no valid root filesystem found
Got it booting after a resize2fs :)
$ resize2fs -MPf yoe-sdk-image-qemuriscv32-20210812183746.rootfs.ext4
resize2fs 1.45.6 (20-Mar-2020)
Estimated minimum size of the filesystem: 725665
Thanks for all the help, @kraj. I have my RISC-V 32 qemu image up and running. I found a couple issues with the patchset, but there's still more work to do. (I need to switch gears and work on a couple issues for the v2.5.2 release of libseccomp.)
The arch_syscall_resolve_num() function is returning NULL for some RISC-V 32 syscalls. You need to add an entry in syscalls.csv in every row for RISC-V 32.
Here are a couple changes I made that helped the tests get further. YMMV. Let me know if you have any questions
diff --git a/include/seccomp-syscalls.h b/include/seccomp-syscalls.h
index 01554fe..12ecc4d 100644
--- a/include/seccomp-syscalls.h
+++ b/include/seccomp-syscalls.h
@@ -283,6 +283,7 @@
#define __PNR_clock_nanosleep -10249
#define __PNR_gettimeofday -10250
#define __PNR_quotactl_path -10251
+#define __PNR_fcntl -10252
diff --git a/src/arch-riscv32.c b/src/arch-riscv32.c
index 53b3126..10418f4 100644
--- a/src/arch-riscv32.c
+++ b/src/arch-riscv32.c
@@ -24,8 +24,8 @@ const struct arch_def arch_def_riscv32 = {
.token_bpf = AUDIT_ARCH_RISCV32,
.size = ARCH_SIZE_32,
.endian = ARCH_ENDIAN_LITTLE,
- .syscall_resolve_name = riscv32_syscall_resolve_name,
- .syscall_resolve_num = riscv32_syscall_resolve_num,
+ .syscall_resolve_name_raw = riscv32_syscall_resolve_name,
+ .syscall_resolve_num_raw = riscv32_syscall_resolve_num,
.syscall_rewrite = NULL,
.rule_add = NULL,
};
@kraj can you please take a look at the comments - 2.5.2 is now out, and the patches that are carried in Yocto for 2.5.1 are difficult to forward-port. So we can't update.
@kraj can you please take a look at the comments - 2.5.2 is now out, and the patches that are carried in Yocto for 2.5.1 are difficult to forward-port. So we can't update.
let me do the update for that package.
Thanks, @kraj. I think you're making good progress. The tests passed on libseccomp's (x86_64) CI, and I ran them on an arm VM where they also passed. I encountered several errors on RISC-V 32, though:
Regression Test Summary
tests run: 4370
tests skipped: 149
tests passed: 4367
tests failed: 3
tests errored: 108
The failures were largely in socket, IPC, and the binary tree logic. How does RISC-V 32 handle multiplexing of sockets/IPC?
Finally, combining the update to Linux v5.15.0-rc3 and the addition of RISC-V 32 into one commit may cause maintenance issues. If we bisect a problem down to that commit, is it because of the kernel change or the RISC change?
@kraj can you please rebase and fix the conflicts again, so we can update to 2.5.3? Would be good to get this merged as well.
@drakenclimber rebased again. I will test again on riscv32 and try to dig into reasons for failures you saw.
@drakenclimber rebased again. I will test again on riscv32 and try to dig into reasons for failures you saw.
Thanks, @kraj. I have my riscv32 VM up and running again. I'll check out the changes this week.
I ran the automated tests on my riscv32 VM. (Out of expediency, I didn't enable python for this test run.)
Regression Test Summary
tests run: 4353
tests skipped: 149
tests passed: 4350
tests failed: 3
tests errored: 118
============================================================
FAIL: regression
==================
1 of 1 test failed
==================
Looks like there were failures in the binary tree, IPC, and socket-related tests.
From what I can see this PR has some test failures, but no follow up with fixes; any updates @kraj?
From what I can see this PR has some test failures, but no follow up with fixes; any updates @kraj?
yeah I had to shift my focus on other things, I can revive this again perhaps next week or so.