@drakenclimber once the Travis runs complete you'll see we have some test failures/errors that we need to hunt down on ppc64le and s390x.

I'm wondering if we're getting bitten by issue #193.

These failures are for shmget, shmat, and shmctl.

Test 53-sim-binary_tree%%034-00001 result:   FAILURE bpf_sim resulted in ALLOW
Test 53-sim-binary_tree%%035-00001 result:   FAILURE bpf_sim resulted in ALLOW
Test 53-sim-binary_tree%%036-00001 result:   FAILURE bpf_sim resulted in ALLOW

Looks like I can reproduce the s390 failures on the s390 VM that @cpaelzer pointed me at earlier. I'll see what I can find.

Looks like I can reproduce the s390 failures on the s390 VM that @cpaelzer pointed me at earlier. I'll see what I can find.

Great, thank you.

s390x is failing on the following tests: 36-sim-ipc_syscalls, 37-sim-ipc_syscalls_be, and 53-sim-binary_tree. I'll focus on tests 36 and 37 in this post.

On my s390x VM, the running kernel is listed below. (I haven't yet tried to update it to a newer version. The VM has very limited networking and throughput; building the kernel on it would be painful. Perhaps I can cross-compile on another machine.)

$ uname -a
Linux libseccompv1 3.10.0-957.21.3.el7.s390x #1 SMP Fri Jun 14 02:52:25 EDT 2019 s390x s390x s390x GNU/Linux

Tests 36 and 37 are failing on my VM because libseccomp is using positive syscall numbers for msgctl, etc. while the system does not have __NR_msgctl, etc. defined. While not the correct answer, making the following change allowed tests 36 and 37 to pass:

--- a/src/arch-s390x-syscalls.c
+++ b/src/arch-s390x-syscalls.c
...
-       { "msgctl", 402 },
-       { "msgget", 399 },
-       { "msgrcv", 401 },
-       { "msgsnd", 400 },
+       { "msgctl", __PNR_msgctl },
+       { "msgget", __PNR_msgget },
+       { "msgrcv", __PNR_msgrcv },
+       { "msgsnd", __PNR_msgsnd },
...
-       { "semctl", 394 },
-       { "semget", 393 },
+       { "semctl", __PNR_semctl },
+       { "semget", __PNR_semget },
        { "semop", __PNR_semop },
-       { "semtimedop", 392 },
+       { "semtimedop", __PNR_semtimedop },

Test 53-sim-binary_tree is failing because the test specifies explicit native syscalls, shmat, etc., but the s390x system is using the IPC version of those syscalls. Since the goal of this test is to verify binary tree performance, I think the best answer is to remove the IPCed syscalls from the test and let other tests (e.g. 37-sim-ipc_syscalls_be) focus on verifying IPC behavior.

Tests 36 and 37 are failing on my VM because libseccomp is using positive syscall numbers for msgctl, etc. while the system does not have __NR_msgctl, etc. defined. While not the correct answer, making the following change allowed tests 36 and 37 to pass ...

Look at what we did in commit bf747eb, specifically the changes in x86_syscall_resolve_name() and x86_syscall_resolve_num(). I think this needs to be done for both s390 and s390x.

Test 53-sim-binary_tree is failing because the test specifies explicit native syscalls, shmat, etc., but the s390x system is using the IPC version of those syscalls. Since the goal of this test is to verify binary tree performance, I think the best answer is to remove the IPCed syscalls from the test and let other tests (e.g. 37-sim-ipc_syscalls_be) focus on verifying IPC behavior.

As long as we've got coverage in tests 36 and 37 I think this is the smart move.

Thanks for debugging this @drakenclimber.

I have the tests passing on both s390x and ppc64le:
https://github.com/drakenclimber/libseccomp/tree/issues/215
Passing TravisCI

Here's what I did:

• Added several syscalls to the s390 and s390x munge functions. Thanks for the pointer, @pcmoore
• Removed IPC syscalls from test 53.
• Made a wild stab at the munge functions for ppc64. I initially tried a more targeted solution, but it failed and I simply don't know which ppc64 syscalls need to be munged. This list is a direct copy of the s390 list

• Added several syscalls to the s390 and s390x munge functions. Thanks for the pointer, @pcmoore
• Removed IPC syscalls from test 53.

Thanks for getting that fixed, want to put together two patches for this and submit a PR? We can at least get s390/s390x enabled.

Made a wild stab at the munge functions for ppc64. I initially tried a more targeted solution, but it failed and I simply don't know which ppc64 syscalls need to be munged. This list is a direct copy of the s390 list.

Ooof. While I'm glad you got it working, I'd like a better explanation of what is going on here. Do we need to treat the various PPC ABIs like x86, s390, etc. and support multiplexed/direct-wired socket/ipc syscalls? It looks like the current upstream kernel has direct-wired socket syscalls, but I don't know if that was always the case.

It looks like the current upstream kernel has direct-wired socket syscalls, but I don't know if that was always the case.

Bummer. A quick search through the Linux Kernel's git log revealed the commit below. It looks like we need to add ppc/ppc64/ppc64le to the list of ABIs that need to have the multiplex/direct-wired dance. @drakenclimber you up for this? I would also suggest checking on the IPC syscalls as well.

commit 86250b9d12caa1a3dee12a7cf638b7dd70eaadb6
Author: Ian Munsie <imunsie@au1.ibm.com>
Date:   Wed Aug 25 18:50:28 2010 +0000

    powerpc: Wire up direct socket system calls
    
    This patch wires up the various socket system calls on PowerPC so that
    userspace can call them directly, rather than by going through the
    multiplexed socketcall system call.
    
    Signed-off-by: Ian Munsie <imunsie@au1.ibm.com>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

It looks like the current upstream kernel has direct-wired socket syscalls, but I don't know if that was always the case.

Bummer. A quick search through the Linux Kernel's git log revealed the commit below. It looks like we need to add ppc/ppc64/ppc64le to the list of ABIs that need to have the multiplex/direct-wired dance. @drakenclimber you up for this? I would also suggest checking on the IPC syscalls as well.

commit 86250b9d12caa1a3dee12a7cf638b7dd70eaadb6
Author: Ian Munsie <imunsie@au1.ibm.com>
Date:   Wed Aug 25 18:50:28 2010 +0000

    powerpc: Wire up direct socket system calls
    
    This patch wires up the various socket system calls on PowerPC so that
    userspace can call them directly, rather than by going through the
    multiplexed socketcall system call.
    
    Signed-off-by: Ian Munsie <imunsie@au1.ibm.com>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

Sure, but if someone has access to a PPC box, that would really be the best answer. Any changes I make will be an educated guess at best. :(

Sure, but if someone has access to a PPC box, that would really be the best answer. Any changes I make will be an educated guess at best. :(

Unfortunately I'm in the same boat. Perhaps ping the Freescale guys who contributed some of the ppc code to see if they can do some testing?

@drakenclimber and @pcmoore I'm still following this thread loosley (thanks for all your efforts) and I have access to ppc64 boxes (I can openstack deploy what I need). So if you come up with a branch of some sort and a set of instructions & tests that I shall run against it I can give it a try.

That's great @cpaelzer, thank you very much for the help. I'm sure @drakenclimber will be in touch when he has something ready to test.

@drakenclimber and @pcmoore I'm still following this thread loosley (thanks for all your efforts) and I have access to ppc64 boxes (I can openstack deploy what I need). So if you come up with a branch of some sort and a set of instructions & tests that I shall run against it I can give it a try.

Thanks so much, @cpaelzer! Give me a few days and I should have a patchset and some instructions to send your way.

I have added the multiplexing support to ppc and ppc64, but I'm still not sure what syscalls need to be munged. I tried wading through the kernel's ppc syscall.tbl but didn't find any enlightenment ;).
https://github.com/drakenclimber/libseccomp/tree/issues/215ppc

I have a request out to IBM to see if I can get access on a PPC cloud VM, but I seem to be lost in bureaucracy at the moment.

I have added the multiplexing support to ppc and ppc64, but I'm still not sure what syscalls need to be munged. I tried wading through the kernel's ppc syscall.tbl but didn't find any enlightenment ;).

Unfortunately I think you can't really go by the current syscall tables as they have most likely all been updated to support the new direct-wired variants. I think you'll need to go back in time to look at historical kernels to see what ABI supported, e.g. what did the ppc/ppc64 ABI support back in Linux v3.5?

NOTE: you don't need to go back further than Linux v3.5 as prior to that seccomp mode 2 did not exist.

Unfortunately I think you can't really go by the current syscall tables as they have most likely all been updated to support the new direct-wired variants. I think you'll need to go back in time to look at historical kernels to see what ABI supported, e.g. what did the ppc/ppc64 ABI support back in Linux v3.5?

NOTE: you don't need to go back further than Linux v3.5 as prior to that seccomp mode 2 did not exist.

Thanks, that helps a lot. As you surmised, the current table was not helpful.

I had started to wade back in time, but I didn't know how far to go, so it was stabbing in the dark. Knowing that v3.5 is roughly the right time frame helps immensely. Thanks!

I had started to wade back in time, but I didn't know how far to go, so it was stabbing in the dark. Knowing that v3.5 is roughly the right time frame helps immensely. Thanks!

Heh, as far as libseccomp is concerned, the dawn of time was Linux v3.5 ;)

Heh, as far as libseccomp is concerned, the dawn of time was Linux v3.5 ;)

As I think of it, that's not 100% correct. Speaking generally, yes, it all started with Linux v3.5, but when we are talking about specific ABIs/arches we need to consider when that ABI added SECCOMP_FILTER support. So you can start looking at Linux v3.5 but I would first check to see what Linux release added HAVE_ARCH_SECCOMP_FILTER support.

For the various PowerPC ABIs it looks like support was first included in Linux v4.3:

# git show 2449acc5348b9 | head
commit 2449acc5348b94325e9374056b2cc3ed55816e96
Author: Michael Ellerman <mpe@ellerman.id.au>
Date:   Thu Jul 23 20:21:09 2015 +1000

    powerpc/kernel: Enable seccomp filter
    
    This commit enables seccomp filter on powerpc, now that we have all the
    necessary pieces in place.
    
    To support seccomp's desire to modify the syscall return value under
# git tag --contains 2449acc5348b9 | grep -e "^v[0-9]\.[0-9]\+$" | sort -V
v4.3
v4.4
v4.5
v4.6
v4.7
v4.8
v4.9
v4.10
v4.11
v4.12
v4.13
v4.14
v4.15
v4.16
v4.17
v4.18
v4.19
v4.20
v5.0
v5.1
v5.2
v5.3
v5.4
v5.5

Thanks to @drakenclimber's latest s390x fixes it looks like s390x is now building correctly on Travis CI so I've merged the patch which enables that. Now we just have ppc64le left to fix.

Coverage remained the same at 92.701% when pulling a2e87f8 on pcmoore:working-travis into 6780d9c on seccomp:master.

Closing this as the ppc64le support will be added as part of PR #229.