arch: add newly connected x86 32bit direct socket calls

[martinpitt]

In Linux 4.3, x86 connected up the direct socket calls to enable seccomp filtering:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9dea5dc921

Add these to the 32 bit x86 syscalls table to match. Otherwise seccomp filters socket() and friends fail with EFAULT. (Thanks to @awhitcroft for the patch!).

I noticed that because merely rebuilding systemd against the Linux 4.3 kernel headers broke nspawn on i386. The linked Launchpad bug has the details and a simple standalone reproducer.

Note that this represents a dependency barrier -- the old code works with Linux <= 4.2, this code works with Linux >= 4.3, but if you mix old/new libseccomp and linux it will break in this manner. Ou of interest, why does libseccomp hardcode all the syscall numbers instead of using the __NR_syscallname macros of the kernel headers? That'd be much more robust against typos, errors like this, and it would enable checks like #ifdef __NR_socket?

Thanks!

[pcmoore]

I am currently working on a patchset to update the libseccomp syscall tables to match the Linux 4.3 release, with resolving the 32-bit x86 direct wired socket syscalls being a big part of the patchset. Unfortunately, due to the compatibility issues you describe, the fix is more complicated than in your pull request; we need something that works on systems that use the multiplexed socket calls as well as new systems that use the direct socket calls.

Also, to answer your question, libseccomp includes syscalls tables to deal with non-native syscall filtering. Without the syscall tables it would be very hard to filter on x86 or x32 syscalls on a x86_64 system, or to generate filters offline for different architectures.

[martinpitt]

Ah, thanks for the explanation about foreign syscall numbers, that makes sense! (Given that this was the situation that I just ran into I should have thought about this myself..) Thanks!

[ohsix]

@pcmoore while looking for a place to file bug, i saw you manage this on rhbz, can you get this into f23?

i miss my containers ;]

[pcmoore]

@ohsix this is the right place to file upstream bugs, RHBZ is the right place for Fedora/RHEL specific libseccomp bugs; when in doubt just file an issue here and I'll make sure it gets handled.

As for upcoming releases, I expect to make a new upstream release early next week, with Fedora Rawhide following soon after, and the latest stable Fedora following after that.

[ohsix]

i found out i was using a kernel from updates-testing and not from 23 per-se; (4.4.2 vs. 4.2.3 respectively) i don't know much about testing, will figure it out

(eg. the problem doesn't happen on '23', but there are updates in the chute where it breaks)

edit:
sorry for the noise, something happened with libseccomp on the host and it was from the @@commandline repo, reinstall somehow fixed it though it was the same version and stuff.

[pcmoore]

It sounds like you have things working again - that's good. As I said earlier, you should see a new libseccomp release soon.