RFE: add RISC-V 64 bit support

[rwmjones]

Adds support for the RISC-V architecture, 64 bit only.

Also adds support for 2 new system calls added since the previous
architecture: preadv2(2) and pwritev2(2).

Signed-off-by: Richard W.M. Jones rjones@redhat.com

[rwmjones]

RISC-V is an open source, free ISA developed at UCB since 2010 (https://riscv.org/).

This patch adds 64 bit (only) RISC-V support to libseccomp.

Let me caveat this patch: There is no kernel support for audit at the moment in the RISC-V fork of the Linux kernel. However I'm going to look at that next.

Nevertheless the patch works for me and passes all the tests on Linux/x86_64.

On Linux/riscv64 one test fails:

Test 04-sim-multilevel_chains%%001-00001 result: FAILURE bpf_sim resulted in KILL

[rwmjones]

http://oirase.annexia.org/tmp/log.txt
^ log from make && make check

It seems in fact there are two failures. How do I get more detail about those failures?

[pcmoore]

Hi Richard,

Thanks for the patch, I haven't had a chance to look at it yet, but it is on my radar. A few quick observations and questions:

• I'm guessing that single test failure is due to open(2) not being defined for RISC-V, check out the workaround we have for AArch64 (similar problem) in tests/04-sim-multilevel_chains.tests.
• Any chance of getting valgrind working on RISC-V?
• Have you tried running the "live" tests on a RISC-V kernel? See SUBMITTING_PATCHES, but basically just run './regression -T live' in the tests directory.

[pcmoore]

Sorry, just realized you mentioned two test failures. A quick glance makes me think the second test failure is for the same reason as the first, the fix should be similar.

[rwmjones]

Re: valgrind, no. I will try the other things you suggested.

[rwmjones]

I have pushed an updated patch which fixes the tests. The new output of make && make check is here:

http://oirase.annexia.org/tmp/log.txt

(Make sure to hit Shift + Reload). The tests now pass.

I had a look at what it would take to implement the kernel side of this, and it's considerably more than I anticipated. I (or someone) do eventually intend to do this, but probably not soon.

[pcmoore]

Thanks for the update. The general approach we've taken is to not merge support for new architectures until there are kernel patches available. Please note that this doesn't mean a kernel -rc release, if there is basic support upstream and the development pace is reasonable, we can always create a new branch with ABI support to aid development/testing and merge that to master once the kernel maintainer gives the nod.

Quick summary: I'm not going to review/merge this now as it sounds like the associated kernel support is a long time off, but please ping us when you are getting ready to work on the kernel support; we'll be happy to help however we can.

[pcmoore]

@rwmjones I just wanted to check back and see how things were going with the kernel support ... any progress worth reporting? If you think this is still a ways off, I'm tempted to close out this PR for the moment as it is only going to get increasingly outdated. However, if you think you might have the kernel support working in a month or two I'm okay with leaving this open.

Thoughts?

[pcmoore]

@rwmjones It's been a while with no feedback so I'm going to close this PR. If/when you get the kernel support in place I'll happily accept RISC-V as a new ABI for libseccomp.

[rwmjones]

Sorry, I don't get github notifications.

So probably closing this is the right thing for now. We're expecting to get the kernel stuff upstream real soon, and then I'll be back working on Fedora/RISC-V and we'll see what the final syscalls look like.

[pcmoore]

No worries. When thing are all set with the upstream kernel we can revisit this - thanks!

[rwmjones]

FYI RISC-V support was merged in Linux 4.15.

However I'm currently not in a position to re-verify the changes. We're looking at restarting the RISC-V work in February 2018 which is the expected date for getting glibc upstream too.

[pcmoore]

Thanks for the update, you know where to find us when you guys are ready.

[shlevy]

@rwmjones Anything I can do to help/any advice for picking this up myself?

[pcmoore]

We're seeing PRs for this now, so it seems like it is time to reopen this issue.

[pcmoore]

Argh, nevermind, I just realized this is a PR and not an issue, let's leave this closed and create a tracking issue.

[pcmoore]

Let's move the discussion to issue #110.