Guide to Linux System Calls (2016)
blog.packagecloud.io
Guide to Linux System Calls (2016)
1–10 of 37 posts
Re: Guide to Linux System Calls (2016)
#2I guess not many actually need to call linux kernel system calls directly bypassing proper measures, but how many fondly remembers int 21h?
Re: Guide to Linux System Calls (2016)
#3I guess not many actually need to call linux kernel system calls directly bypassing proper measures, but how many fondly remembers int 21h?
I fondly remember INT 21h, and reading the 40Hex magazine along with Ralph Brown's interrupt list.
I was recently working on generating some assembly language output and I added the ability to generate a breakpoint at the start of my executable.
It took me an embarassingly long time to realize that the reason my executables were crashing, not dropping into the debugger, was that "INT3" was assembled differently than "INT 03h" - I knew I needed 0x03, and I knew it was the one-byte form of the instruction (0xCC) rather than (0xCD 0xNN), to ease patching, but .. yeah.
Re: Guide to Linux System Calls (2016)
#4> Calling system calls by crafting your own assembly is generally a bad idea as the ABI may break underneath you.
syscall should have a stable ABI at the very least, because this would otherwise break all statically linked code.
Re: Guide to Linux System Calls (2016)
#5> Calling system calls by crafting your own assembly is generally a bad idea as the ABI may break underneath you. syscall should have a stable ABI at the very least, because this would otherwise break all statically linked code.
Yep, that's wrong. There's no way Linus would ever let such a change get merged.
Re: Guide to Linux System Calls (2016)
#6> Calling system calls by crafting your own assembly is generally a bad idea as the ABI may break underneath you. syscall should have a stable ABI at the very least, because this would otherwise break all statically linked code.
That is true for Linux but might not be true for other operating systems though.
Re: Guide to Linux System Calls (2016)
#7> Calling system calls by crafting your own assembly is generally a bad idea as the ABI may break underneath you. syscall should have a stable ABI at the very least, because this would otherwise break all statically linked code.
Yes, that doesn't make much sense. Linux syscall interface is stable whether or not you use glibc or not.
Re: Guide to Linux System Calls (2016)
#8> Calling system calls by crafting your own assembly is generally a bad idea as the ABI may break underneath you. syscall should have a stable ABI at the very least, because this would otherwise break all statically linked code.
That is true for Linux but might not be true for other operating systems though.
The article is specifically about _Linux_ system calls.
Re: Guide to Linux System Calls (2016)
#9> Calling system calls by crafting your own assembly is generally a bad idea as the ABI may break underneath you. syscall should have a stable ABI at the very least, because this would otherwise break all statically linked code.
That is true for Linux but might not be true for other operating systems though.
It is absolutely not true on many (most?) operating systems; Linux is actually an outlier, and we mostly forget that it's the odd one out because it's so popular. Off the top of my head, I believe both NT and Solaris define libc as the stable interface that userspace uses; I don't recall exactly what the BSDs do, but I suspect that they at least strongly encourage using libc and not trying to talk to the kernel yourself (IIRC OpenBSD does this because some of their security measures are managed by libc). Go has hit this a few times because they don't want to depend on libc if they can avoid it, but on a lot of systems they really can't avoid it.
Ah, here we go: https://github.com/golang/go/issues/36435
> Upcoming changes to the OpenBSD kernel will prevent system calls from being made unless they are coming from libc.so (with some exceptions, for example, a static binary). There are also likely to be changes to the APIs used for system calls. As such, the Go runtime (and other packages) need to stop using direct syscalls, rather calling into libc functions instead (as has always been done for Solaris and now also for macOS).
(and the "with some exceptions" is why I say "strongly encouraged")
Re: Guide to Linux System Calls (2016)
#10Earlier quoted context omitted.
That is true for Linux but might not be true for other operating systems though.
It is absolutely not true on many (most?) operating systems; Linux is actually an outlier, and we mostly forget that it's the odd one out because it's so popular. Off the top of my head, I believe both NT and Solaris define libc as the stable interface that userspace uses; I don't recall exactly what the BSDs do, but I suspect that they at least strongly encourage using libc and not trying to talk to the kernel yours…
macOS, in some sense a BSD (at least nominally), would like you to not make system calls yourself as well. Actually, not linking against libc has a number of hilarious consequences, one of which is that you bypass the platform sandbox because apparently the engineers thought it couldn't be possible to write a program without it :P