BUG: check direct syscall before multiplexed pseudo-syscall

[nikita-dubrovskii]

Docker 29.4.2 removed socketcall(2) from the default seccomp profile. On s390x, this broke socket operations:

  # strace curl icanhazip.com
  socket(AF_UNIX, SOCK_STREAM, 0) = -1 ENOSYS (Function not implemented)

  # scmp_sys_resolver -a s390x socket
  -101

  # ausyscall s390x socket
  socket             359

The abi_syscall_resolve_name_munge() function was returning __PNR_socket (-101) instead of checking if arch implements socket(2) directly (359).

Fix by checking arch->syscall_resolve_name_raw() first, only falling back to multiplexed pseudo-syscalls if the direct implementation doesn't exist.

Affects socket and IPC syscalls on architectures with direct implementations (s390x, aarch64, etc).

[nikita-dubrovskii]

This won't fix Docker itself, but at least the tools will return the correct values:

[zukku@a3elp43 libseccomp]$ scmp_sys_resolver socket
-101

$ LD_PRELOAD=./src/.libs/libseccomp.so scmp_sys_resolver socket
359

[pcmoore]

We need to be careful with changes like this as it is changing the behavior of the library in a way that might not be friendly to all of the users.

[pcmoore]

Marking this as a BUG for now, but until we understand the impact of a change like this we need to take the classification with a grain of salt ...

[drakenclimber]

I think having libseccomp use the "standard" syscall before the multiplexed pseudo-syscall is a good discussion to have, but as @pcmoore pointed out, the ramifications could be large. We would definitely have to proceed with caution if we were to make such a change.

With that said, is this still urgent? It looks like Docker v29.4.3 [1] fixed this. Correct?

[1] moby/moby#52555

[nikita-dubrovskii]

With that said, is this still urgent? It looks like Docker v29.4.3 [1] fixed this. Correct?

Yes, it should be working now.

I think having libseccomp use the "standard" syscall before the multiplexed pseudo-syscall is a good discussion to have, but as @pcmoore pointed out, the ramifications could be large.

After checking git history, i have an impression, that current behaviour was implemented as a workaround many years ago. Than several updates like this with some mux/demux, and finally consolidation moved all logic to centralized functions. But! Bug was still there - instead of returning direct syscall, code always returned multiplexed.

The code DID work:

1. Name resolution (buggy): abi_syscall_resolve_name_munge("socket") returned __PNR_socket (-101) instead of 359
2. Dual-rule generation in abi_rule_add() logic:
   • one for direct syscall
   • one for multiplexed

This fix doesn't break rule generation, as abi_rule_add() works correctly regardless of whether you start with the direct syscall (359) or pseudo-syscall (-101).

This is my understanding.

[drakenclimber]

The code DID work:

1. Name resolution (buggy): abi_syscall_resolve_name_munge("socket") returned __PNR_socket (-101) instead of 359

2. Dual-rule generation in abi_rule_add() logic:

   • one for direct syscall
   • one for multiplexed

This fix doesn't break rule generation, as abi_rule_add() works correctly regardless of whether you start with the direct syscall (359) or pseudo-syscall (-101).

This is my understanding.

Thanks. Your research is thorough and spot on.

The worry I have is that this will change the default multiplexing behavior for all users on all architectures. I don't know what the fallout would be in that case.