Is it possible to intercept syscalls with a custom code from inside the program?

Question

I have a binary calling syscall with a code not present on the Linux kernel.

Is it possible that the binary catches the syscall by itself and handles it on-the-fly?

Furthermore, what happens if I call syscall with an invalid code? e.g. syscall(666, args...)

I've searched the internet for answers and didn't find anything. I am aware that syscalls are defined when the kernel boots, so getting an "exotic" syscall to works seems weird at least.

Answer 1

I think intercepting system calls can be done in at least 3 ways:

1. registering a handler for the SIGSYS signal
2. using seccomp() to filter system calls
3. selective syscall userspace redirection with prctl()

From Emulating Windows system calls in Linux:

To run with any speed at all, Wine must run Windows code directly on the CPU to the greatest extent possible. That must end, though, once the Windows program makes a system call; trapping into the Linux kernel with the intent of making a Windows system call is highly unlikely to lead to good results. Traditionally, Wine has handled this by supplying its own version of the user-space Windows API that implemented the required functionality using Linux system calls. As explained in the patch posting, though, Windows applications are increasingly executing system calls directly rather than going through the API; that makes Wine unable to intercept them.

The good news is that Linux provides the ability to intercept system calls in the form of seccomp(). The bad news is that this mechanism, as found in current kernels, is not suited to the task of intercepting only system calls made from Windows code running within a larger process. Intercepting every system call would slow things down considerably, an effect that tends to make gamers particularly cranky. Tracking which parts of a process's address space make Linux system calls and which make Windows calls within the (classic) BPF programs used by seccomp() would be awkward at best and, once again, would be slow. So it seems that a new mechanism is called for.

The patch set adds a new memory-protection bit for mmap() called PROT_NOSYSCALL which, by default, does not change the kernel's behavior. If, however, a given process has turned on the new SECCOMP_MODE_MMAP mode in seccomp(), any system calls made from memory regions marked with PROT_NOSYSCALL will be trapped; the handler code can then emulate the attempted system call.

More info:

• [PATCH v3 1/2] kernel: Implement selective syscall userspace redirection
• Emulating Windows system calls, take 2
• Syscall User Dispatch