32bit glibc calls old socketcall() syscall, causing seccomp problems

setting to high, that makes some snap not work on i386

Hi, glibc was updated to use the new syscalls in 16.04, and does not use socketcall. Previous editions should not be updated.

However the problem that Sebastien has, and has also been reported to Docker, is that libseccomp in 16.04 has not been updated to 2.3.0 which supports the direct non socketcall syscalls for i386, so any 32 bit process using seccomp cannot perform socket operations on 16.04, eg Steam.

I'll take a look at this. I'll try an updated libseccomp with xenial's glibc and a > 4.2 kernel and if this works, I'll pursue an SRU. Is there a simple test case or snap that I can use to verify it is broken with old seccomp and working with new?

@Jamie, the gnome-calculator one on i386 with confinment enabled hits a system call error, I'm happy to test candidate debs if that's useful

Note, this affects even hello-world.

hello-world.sh that is.

Status changed to 'Confirmed' because the bug affects multiple users.

While this bug is still open, developers may either:

* install snaps with --devmode (eg, snap install --devmode /path/to/snap)
* add 'socketcall' to /var/lib/snapd/seccomp/profiles/snap.your.app

FYI, >=16.10 has libseccomp >= 2.3. xenial has 2.2.3-3ubuntu3 that includes updated syscall tables for this (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=809556 and https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1554098).

>=16.04 have 4.4 kernels and updated glibc.

Fwiw, this is longer working on zesty and newer:
"""
#include <stdio.h>

#include <seccomp.h>

int main(int argc, char **argv) {
  int sys_num = seccomp_syscall_resolve_name("socket");
  printf("%d ", sys_num);
}
"""
returns -101 now. I think I know what is going on and will provide a patch shortly.

So to summarize: in zesty, artful `scmp_sys_resolver -a x86 socket` will return: `-101`. The syscalls are still there in the kernel and libc its just that libseccomp reports a pseudo number again (which it did not in xenial).

The reason why we are seeing negative syscall numbers from libseccomp again is: https://github.com/seccomp/libseccomp/commit/73d83e45efbe8c31067c97155162f17ca51b7435

The interessting question is what we should do - the most simple answer is to just revert this, this would be consistent with xenial. But given that its an upstream commit I'm hesitant to do this.