Add support for RISC-V 32-bit & 64-bit (riscv32, riscv64)

[davidlt]

The testing was done only on riscv64 using Fedora 29 w/ kernel 4.19.0-rc8. To my knowledge there are no Linux distributions planning to support riscv32. Note, there is no COMPAT support, i.e., riscv32 applications cannot run on riscv64 host.

The following was checked:

• auditctl (checked several different example rules from internet)
• aulast
• aulastlog
• ausearch
• ausyscall
• aureport
• autrace (compared some syscalls to strace: order and return value/input arguments seem to be correct)

I looked at audit-testsuite and modified it for riscv64. See: https://github.com/davidlt/audit-testsuite/tree/riscv64

The current results would be:

Failed 4/14 test programs. 19/88 subtests failed.

Failures:

• syscall_socketcall: that's an old stuff and not relevant to new arches;
• syscall_module: Fedora kernel is not compiled with kernel loadable module support;
• filter_exclude: 2 tests fail because 'id -Z' doesn't print any categories, but 'semanage login -l' output is identical between x86_64 and riscv64;
• netfilter_pkt: Fedora don't have CONFIG_IP_NF_MANGLE enabled.

Fedora kernel currently has minimal CONFIG_* options enabled and is built without loadable module support.

I hope to send the kernel patches later today.

Signed-off-by: David Abdurachmanov [email protected]

[davidlt]

Kernel patchset: https://www.redhat.com/archives/linux-audit/2018-October/msg00098.html

[stevegrubb]

Hello,

I just wanted to leave a note and not leave this hanging. I have not pulled this in because I am not sure about maintaining another table. I pulled in alpha a long time ago and they disappeared never to be seen again. I think I am going to deprecate that table as well as IA64 to reduce the maintenance burden. Aside from that, I don't think there is anything technically wrong with the patch.

[davidlt]

This has been included in Fedora/RISCV for some months now and it works without a flaw (as far as I used it). So far everything worked as expected. There is one thing I would remove -- riscv32 support. So RISC-V 32-bit support is being dragged a bit in glibc and thus syscall table is changing compared to riscv64. There are a few changes already and more coming (related to year 2038 problem).

The plan was/is to get RISC-V 32-bit ABI finalized in the next glibc release, but I am not sure if that will happen.

[davidlt]

Is there a way we could move forward and add RISC-V support? I would love to have RISC-V support in a release sooner than later as that's easier to distributions to pick up. There are a number of Linux distributions already supporting riscv64 (Fedora, Debian, OpenSUSE, OpenEmbedded, Gentoo, etc).

[davidlt]

Ping. I would like to know how to move forward here.

[stevegrubb]

I am reluctant to add more architectures to audit user space. The main reason is it takes a lot of time updating the syscall tables and no one really helps. I got stuck taking care of the Alpha processor and IA64 after a promise of help and then they disappeared. If there were more contributors to the audit subsystem, it might be another story.

[thesamesam]

Might be worth borrowing some of the infrastructure from systemd which has some scripts to do this.

[menmazqj]

I am reluctant to add more architectures to audit user space. The main reason is it takes a lot of time updating the syscall tables and no one really helps. I got stuck taking care of the Alpha processor and IA64 after a promise of help and then they disappeared. If there were more contributors to the audit subsystem, it might be another story.

Hi, @stevegrubb. This is 2024! Thanks for your work. We have a couple people working on RISCV stuff, like building the RISCV ecosystem. I'm curious why this PR hasn't been merged. Do we need to move this work forward?

[davidlt]

I plan to update the patch based on v6.8 or/and v6.9 in near time. I have not been pushing newer versions of this PR. This is probably the largest non-upstream patch we have in Fedora/RISCV for longest now.

[menmazqj]

I checked the historical PRs and ultimately understood why new architectures were not introduced in this repo. I think we should move the arch support patches to the places needed. Thanks again for @stevegrubb and @davidlt .