9 ms·
Linux System Call Table
- kahlonel 9y agoThis is very handy with the asm registers mapped to arguments. Thanks!
- dmix 9y agoNice, I'm curious how it maps the system call to the source code line number dynamically? (Edit: seems like ctags + http://elixir.free-electrons.com/linux/latest/source http://elixir.free-electrons.com/linux/latest/source [1]) It supports every kernel version. 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/master/gen_syscalls.py https://github.com/thevivekpandey/syscalls-table-64bit/blob/...
- eatonphil 9y agoThis is great! It would be even more useful to have this for Mac OSX too. A lot of the projects I do ends up being on both Mac and Linux. It's always a pain to find the corresponding number for the system call on Mac.
- legulere 9y agoSystem calls have not stability guarantee on macOS. You should use libc instead. In general the use of syscalls directly is fairly limited. Edit: for instance go broke once for macOS Sierra, when Apple changed the gettimeofday system call: https://github.com/golang/go/issues/16570 https://github.com/golang/go/issues/16570
- zzzcpan 9y agoLinux doesn't guarantee syscall stability either. Just make sure your wrappers can use a syscall table chosen at runtime, depending on which kernel you are running.
- smhenderson 9y agoif you're going to implement that kind of overhead why not just use libc?
- zzzcpan 9y agoI'm not sure what you mean by overhead. It's not that hard or expensive to choose a few function pointers on program start.
- wahern 9y agoYes it does, at least in the sense that syscalls which become officially public will never be removed from Linus' tree except in rare circumstances (i.e. proof that nobody is using it), nor will the arguments change. This is Linus' famous "never break user space" ABI mantra. While distributions may deprecate and remove them (e.g. sysctl(2)) they certainly won't be assigned new IDs. A table won't help in such cases.
- caf 9y agoExactly. This is why, for example, the original 'mmap' system call entry point on x86 still exists, even though it is overwhelmingly likely that every program on your machine is actually going to use the 'mmap2' entry point.
- RJIb8RBYxzAMX9u 9y agoI think you're confusing driver APIs and syscalls. Both are infamous for their respective lack of, or guarantee of stability.
- dungle6 9y agoYour first sentence is absolutely false. The syscall table is the stable API of the linux kernel.
- int_19h 9y agoLooking at this bug, it seems that Go has "fixed" it by fixing the syscall arguments, not by switching to libc. 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?
- legulere 9y agoThe problem go has is that there’s a rather large overhead for calling C functions [1]. So they did not switch to calling libc as far as I know. And yes the next time Apple changes the syscalls, it will break again. [1]: https://groups.google.com/forum/m/#!topic/golang-nuts/RTtMsgZi88Q https://groups.google.com/forum/m/#!topic/golang-nuts/RTtMsg...
- int_19h 9y agoWow. So, basically, Go is a rather insular ecosystem - since you're paying the overhead of a context switch for every single FFI call - and if you use the stock APIs, it's essentially broken by design on macOS (since it uses APIs that Apple itself does not consider stable). That's really sad. I was just beginning to like some aspects of it.
- zzzcpan 9y agoThere is a bsd/kern/syscalls.master file for every kernel at https://opensource.apple.com/source/xnu/ https://opensource.apple.com/source/xnu/
- amluto 9y agoI'm a bit puzzled. The code is at "syscalls-table-64bit", yet the regs are eax, etc. This makes very little sense. In any event, I think the args should just be labeled arg0..arg5.
- LukeShu 9y agoIn several cases, the order of the args for a syscall varies between architectures--writing a general "arg0" doesn't make a lot of sense. That said, I don't know what's up with it using 32-bit register names.
- webreac 9y agoIf man pages were up to date, this should be the index of chapter 2. I have discover unix with sun in the 90s and I am very nostalgic of the quality of man pages. At that time, man pages were complete and up to date. My latest frustration was with the option -m of df command. Chapter 2 should be updated each time a new version of kernel is installed.
- mjw1007 9y agoIt's very strange that adding/updating documentation isn't treated as a basic requirement for a patch that adds to or modifies Linux's public interfaces.
- milcron 9y agoFor the BSDs, incorrect or missing man pages are considered a serious bug.
- dom0 9y agoMan pages aren't even in the kernel tree.
- caf 9y agoFrom Documentation/process/submit-checklist.rst: 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.
- vog 9y agoIf you want that level of quality, don't use Linux, use instead FreeBSD or OpenBSD.
- valarauca1 9y agoMichael Kerris keeps and up to date reference [1]. Even details _all_ system calls [2]. [1] https://www.kernel.org/doc/man-pages/ https://www.kernel.org/doc/man-pages/ [2] http://man7.org/linux/man-pages/dir_section_2.html http://man7.org/linux/man-pages/dir_section_2.html
- fbourque 9y agoNice work. the table has been generated for 4.10 and hence the link to the source code files should also have this kernel version in the path of the url for direct access
- throwaway613834 9y agoWhat is the use case for this? Is it for someone trying to write their own syscall wrappers?
- yalue 9y agoSometimes, yes, you'll need to write your own syscall wrappers. For example, there isn't a gettid (get thread ID) function in Glibc, but you can work around this by calling the syscall directly. 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.
- deleted 9y ago[deleted]
- Manozco 9y agoYou might need that when you want to reimplement Linux, the Joyent team did that on their OS (derived from solaris) so that user can run linux binaries on a solaris kernel (so thay have dtrace, zfs, mdb, ...) Bryan Cantrill did a bunch of conferences on that (one here: https://youtu.be/TrfD3pC0VSs https://youtu.be/TrfD3pC0VSs) 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)
- yjftsjthsd-h 9y agoFor that matter, this is how Widows's Linux compatibility layer works.
- ajross 9y agoFreeBSD had a linux syscall layer before either of those, I believe.
- akrasuski1 9y agoThat's all cool and everything, but the registers are wrong... Not only are they 32-bit (eax vs. rax), but their order is wrong too - the first argument in x86-64 ABI is rdi, for example.
- khedoros1 9y agoThe registers look correct for the i386 ABI. eax for the system call number, then ebx, ecx, edx, esi, edi, ebp for the next 6 arguments. 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? https://github.com/thevivekpandey/syscalls-table-64bit https://github.com/thevivekpandey/syscalls-table-64bit
- language 9y agoAh, this is neat! Would be nice to have a script for this that you could just point at a local copy of the source tree too!
- sigjuice 9y agoThis man page describes the syscall ABI for all architectures. http://man7.org/linux/man-pages/man2/syscall.2.html http://man7.org/linux/man-pages/man2/syscall.2.html
- caf 9y ago...and the syscalls(2) man page lists them: http://man7.org/linux/man-pages/man2/syscalls.2.html http://man7.org/linux/man-pages/man2/syscalls.2.html
- akrasuski1 9y agoActually, the syscall numbers are wrong! This reference seems better: http://blog.rchapman.org/posts/Linux_System_Call_Table_for_x86_64/ http://blog.rchapman.org/posts/Linux_System_Call_Table_for_x... Consider simple C program: #define _GNU_SOURCE #include <unistd.h> int main(){ syscall(276); } Strace'ing it shows the syscall used is tee, just as the reference I linked shows, and not pwritev as in OP's table.
- scott_s 9y agoI think you're right - the submitted table has no entries for "fork" and "clone".
- usr1106 9y agostrace is not a proof. It has it's own built-in table. So also strace could be wrong. 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.
- voltagex_ 9y agoIt's odd. The owner of this Git repo has Issues turned off so I can't post a question/issue, and it appears to have been auto-generated - https://github.com/thevivekpandey/syscalls-table-64bit https://github.com/thevivekpandey/syscalls-table-64bit is a "fork" of https://github.com/paolostivanin/syscalls-table-64bit https://github.com/paolostivanin/syscalls-table-64bit
- zokier 9y agoSo the issues noticed so far: * 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.
- Skunkleton 9y agoAt least for x86, you can get this same information fairly easily directly from the source. The table is located at arch/x86/entry/syscalls/syscall_64.tbl, from there you can grep for the function with git grep. For example, git grep 'SYSCALL_DEFINE.*read'.
- tomsthumb 9y agowhy bother with git grep vs. just vanilla grep. i could see the use if you're working with an older binary, but you didn't mention.
- Skunkleton 9y agoIf you ran something like grep -r SYSCALL_DEFINE.read from the top level of the linux source it would search through not just your source code, but also all of the artifacts of building the kernel. Basically, git grep is faster in this case because it filters the searched files down to only ones that are checked in. You could achieve a similar effect with standard tools like this: find -type f -regex '.\.[hc]' | xargs grep 'SYSCALL_DEFINE.*read'
- leni536 9y agogrep -r --include='*.[hc]' 'SYSCALL_DEFINE.*read'
- Skunkleton 9y agoNice. I hadn't used --include before.
- rhinoceraptor 9y agoSomeone should put together a list of which ones are irredeemably broken (and as such, humanity is stuck with a broken ABI in perpetuity), e.g. epoll.
- spilk 9y agoWhat about non-x86/64 platforms?
- kwoff 9y agoI put out a syscall table back in the day for Linux 2.2 (up to %eax 190). Someone copied it (I'm glad.): https://www.cs.utexas.edu/~bismith/test/syscalls/syscalls32.html https://www.cs.utexas.edu/~bismith/test/syscalls/syscalls32.... They didn't attribute it to me, but I remember a professor did for his class. There were better tables after that I admit, though I liked my version because it linked into the source code.
- smegel 9y agoDo system calls put their return value on the calling threads stack or in a register?
- a3f 9y agoAFAIK, A process isn't required to have a stack.
- guhcampos 9y agoThe mere fact that we are debating over the correctness of this table confirms the quality of the documentation of the OS we base our entire civilization upon is pretty poor.
- dungle6 9y agoNot really. Any idiot on the internet can put a poorly made piece of documentation for anything, as has been done here. The topic kernel development is also technically involved and frankly a very small minority of the tech world is intimately familiar with it (let alone in a position to make good use of the documentation), so it's not terribly surprising that there is some discussion over it.
- jared0x90 9y agoThere are tables in the kernel git repo if you want a good reference for their values; however, the register definitions aren't provided. x86: https://github.com/torvalds/linux/blob/master/arch/x86/entry/syscalls/syscall_32.tbl https://github.com/torvalds/linux/blob/master/arch/x86/entry... x64: https://github.com/torvalds/linux/blob/master/arch/x86/entry/syscalls/syscall_64.tbl https://github.com/torvalds/linux/blob/master/arch/x86/entry...
- known 9y agoLatest complete list is at http://elixir.free-electrons.com/linux/latest/source/include/linux/syscalls.h http://elixir.free-electrons.com/linux/latest/source/include...