Linux System Call Table(thevivekpandey.github.io) |
Linux System Call Table(thevivekpandey.github.io) |
* Missing syscalls
* Wrong syscall numbers
* Wrong calling convention
* Links to source are to wrong version
Does the table get actually anything right? I mean this is pretty spectacular cascade of failures.
Consider simple C program:
#define _GNU_SOURCE
#include <unistd.h>
int main(){
syscall(276);
}
In practice strace is widely used and bugs should be discovered, reported, and fixed soon. So without doing any own analysis I'd bet that in doubt this table is wrong and strace right.
Note that syscall list and numbers are architecture specific. The differences are typically not huge, but they exist.
19) All new userspace interfaces are documented in ``Documentation/ABI/``.
See ``Documentation/ABI/README`` for more information.
Patches that change userspace interfaces should be CCed to
linux-api@vger.kernel.org.The linked source code browser seems like a useful way to check the history of system calls for research...
[1] https://github.com/thevivekpandey/syscalls-table-64bit/blob/...
I skimmed a couple files in the code. And it seems like it might be parsing this information out of some other sources, and maybe getting confused about the info it's grabbing?
x86: https://github.com/torvalds/linux/blob/master/arch/x86/entry...
x64: https://github.com/torvalds/linux/blob/master/arch/x86/entry...
In any event, I think the args should just be labeled arg0..arg5.
That said, I don't know what's up with it using 32-bit register names.
The idea behind is that Linux is only a list of syscalls, if you are able to reimplement them, you reimplement linux, you don't need anything else. On the contrary if you want to reimplement a BSD you need to reimplement their libc (and perhaps some other libraries)
To clarify, what you're saying is that in BSD land, the syscall API is not considered stable, but libc is?
But yeah, it's for writing your own syscall wrappers. Something not exported by libc, or more likely if you're not using libc.
The other case where this is useful is if you're wanting to write userspace assembly without calling a C library. This may be especially useful when you're writing a compiler, or if you're trying to write small shellcodes for some reason.
Edit: for instance go broke once for macOS Sierra, when Apple changed the gettimeofday system call: https://github.com/golang/go/issues/16570
Did they switch to libc since then?
If not, and given that Go apps are normally statically linked, does this mean that any precompiled Go app basically has a time bomb, in a sense that it'll break next time Apple changes some syscall?
- Linux has always been described as just a kernel, which translates as just a syscall table. The fact that this table is stable or not is not relevant here.
- *BSD on the other hand are shipping a kernel plus a lot of libraries/binaries, if you want to simulate a BSD system, you have to expose those libraries/binaries.
It's not so much a technical difference, it's more of a different approach to OS development (kernel space vs kernel/user space).
So stability of syscall API is the de facto differentiating factor here. It sounds like Microsoft couldn't do "Windows Subsystem for BSD" the way it did WSL, for example.
[1]: https://groups.google.com/forum/m/#!topic/golang-nuts/RTtMsg...
That's really sad. I was just beginning to like some aspects of it.
grep -r --include='*.[hc]' 'SYSCALL_DEFINE.*read'They work fine even where git-grep is not an option. Example:
ack 'SYSCALL_DEFINE.*read'