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

[davidlt]

That's a bug, need to remove sys_ prefix.

[davidlt]

This also shouldn't be here.

[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 .

[andreabolognani]

@davidlt now that we have GA 6.11 in Fedora, would it make sense to rebase and pick up the changes?

I also wonder if dropping riscv32 and limiting support to riscv64, the only architecture which distros shipping audit will realistically ever target, might make the changeset slightly more palatable to the maintainers.