Fix handling of rseq syscall

[A-dead-pixel]

The current libseccomp in libseccomp.cmake (2.3.3 from 2018) was made for Linux v4.15-rc7 and doesn't know about the rseq (334) syscall, which seems to always be caught on my machine (kernel 5.19.12, Artix Linux) when using default options (just sio2jail -b dir:/ exe). If built with the old libseccomp, an exception is thrown, as we try to convert NULL to string when we can't resolve 334 to rseq. When we use a modern libseccomp, it is properly reported that we use a forbidden syscall.

So this pull request:

• adds a proper, descriptive exception for when libseccomp can't resolve the name of a syscall
• updates libseccomp in libseccomp.cmake
• adds rseq to the list of syscalls allowed by the default seccomp policy
• formats code with make clang-format.

Additional question: Who should I contact to request packaging sio2jail with this fix into a sandbox for sio2?

[Michcioperz]

Hi, thanks for the PR. (Just for clarity I'm not properly involved with the project, but I'm curious about a few things.)

From what I remember old seccomp was used specifically because a newer version at the time of sio2jail's release had a drastic performance regression (I'm assuming @Wolf480pl might remember this better). So I imagine sending this to production would require some more testing.

What do you mean by saying it is "always caught on newer kernels"? Do you mean that any, however simple, C/C++ program triggers the error on newer kernels? (This would sound weird, I'd sooner expect this to be related to libc.)

[A-dead-pixel]

Yes, even int main(){} causes the error. You are right, the issue isn't caused by the kernel itself, but by a relatively new libc, which uses the syscall. If compiled in sio2's gcc 4.8.2 sandbox, it runs correctly. Also, from what I can see on the web, when executing on a kernel without support for it, rseq won't be used. I'm guessing you meant the regression discussed on this thread and PR, which seems to have been resolved in 2019.

[Michcioperz]

Yeah, judging by the issue being authored by varqox, this is probably the right one. FYI there exist newer sandboxes than the gcc 4.8.2 one http://downloads.sio2project.mimuw.edu.pl/sandboxes for instance the gcc 10.2 one seems to be used at this and last year's olympiads.