Apparently now libseccomp defines the new syscall numbers.

[dwrensha]

This undoes #1488. Apparently the latest libseccomp now defines the values? I'm curious whether this will pass in Jenkins...

[dwrensha]

Fascinating. Apparently __NR_seccomp and __NR_bpf are still not defined.

[dwrensha]

It looks like these libseccomp commits got pushed to master yesterday. They include seccomp/libseccomp@d2ca11b, which defines __NR_userfaultfd.

Unfortunately, it gets defined to -10200, which, as far I understand, is not the correct value (and I verified that this is indeed what the Sandstorm supervisor ends up seeing for the value). I guess that this is just meant to be a dummy value?

I'm also confused about why such a definition would exist for the userfaultfd syscall but not for the seccomp and bpf syscalls.

Does anyone have a better understanding of what's going on here? @amluto?

[dwrensha]

This seems to indicate that we should move our #ifndef __NR_userfaultfd so that it happens before we #include <seccomp.h>.

[amluto]

Yuck. They should not be injecting incorrect definitions like that. I'll complain at them. At some point we should drop libseccomp. It's problematic for a few reasons.

[kentonv]

Yeah uh IMO this is a security flaw in libseccomp -- presumably this means that if you build the supervisor against old headers, you silently end up with a sandbox that doesn't filter the newer syscalls. That's really bad!

@amluto I'm always happy to indulge in more NIH. ;)

[kentonv]

Hmm actually I suspect what they're doing is making up for old kernel headers by falling back to internal tables. Presumably the weird negative value gets mapped through a table inside the library to get the correct value for the host platform. We should probably test to find out.

It's still weird that they'd override the __NR_* constants which are used by more than just libseccomp. This could mean that someone who uses the syscall() function ends up making a totally bogus syscall.

[amluto]

I filed:

seccomp/libseccomp#27

[dwrensha]

Closing due to #1672