[HN Gopher] Guide to Linux System Calls (2016)
___________________________________________________________________
Guide to Linux System Calls (2016)
Author : crunchbang123
Score : 98 points
Date : 2020-06-28 11:56 UTC (11 hours ago)
(HTM) web link (blog.packagecloud.io)
(TXT) w3m dump (blog.packagecloud.io)
| loopz wrote:
| I guess not many actually need to call linux kernel system calls
| directly bypassing proper measures, but how many fondly remembers
| int 21h?
| jeffreygoesto wrote:
| _raising hand_ Plus of course int13 for BIOS...
| stevekemp wrote:
| 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.
| saagarjha wrote:
| > 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.
| kyberias wrote:
| Yes, that doesn't make much sense. Linux syscall interface is
| stable whether or not you use glibc or not.
| josephcsible wrote:
| Yep, that's wrong. There's no way Linus would ever let such a
| change get merged.
| ufo wrote:
| That is true for Linux but might not be true for other
| operating systems though.
| yjftsjthsd-h wrote:
| 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")
| pjmlp wrote:
| Only UNIX based OSes use libc as part of the stable
| interface, which on UNIXes case actually means ISO C +
| POSIX.
|
| On non-POSIX OSes like NT and plenty of others, libc is
| part of whatever compiler one decides to use and as such
| not part of any OS interface as such.
|
| On NT the stable OS APIs are provided via the OS
| personalities, meaning OS/2 (dead now), the old POSIX one
| (also dead and replaced by WSL), and Win32 (actually User,
| Kernel, GDI as the main ones), which as of Windows 8 and
| MinWin refactoring is split into redirection dlls know as
| API sets, https://docs.microsoft.com/en-
| us/windows/win32/apiindex/wind....
|
| Which is why on code that never intends to be portable, you
| will see calls like ZeroMemory instead of memset.
| yjftsjthsd-h wrote:
| Oh, interesting; I'd assumed that NT was just using libc
| as its stable ABI, but on further reading it looks more
| like ntdll.dll (probably just for that personality?).
| Similar concept, slightly different place. Still, my
| point was that under the "Windows" personalities, you
| talk to a library, never directly to the kernel.
|
| EDIT: Found https://web.archive.org/web/20121224002314/ht
| tp://netcode.cz... which if I'm reading right indicates
| that ntdll is indeed the bottom-layer library that's
| allowed to actually talk to the kernel.
| pjmlp wrote:
| Yes, ntdll is the lowest level, but you aren't supposed
| to use it directly, and if you do, well no one is going
| to help when a patch Tuesday or something like that
| breaks the application.
|
| The personality DLLs are the applications entry point
| with the kernel.
| monocasa wrote:
| Most of ntdll.dll is officially sanctioned at this point.
| It's officially documented, and obviously plays into the
| backwards compat choices they make.
| ChrisSD wrote:
| Sort of. Many NT functions are officially documented. But
| they're also officially documented as unstable. They
| probably won't break many of the oldest functions but
| they reserve the right to do so at some point.
| saagarjha wrote:
| 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
| khrbtxyz wrote:
| Is there an example somewhere on how to link without libc
| and make my own syscalls? I tried this a while ago (can't
| remember which version of macOS it was), fiddling with
| Csu, nasm etc. but couldn't quite figure it out.
| saagarjha wrote:
| -static -nostdlib, and make sure you have an entry point
| set.
| [deleted]
| kyberias wrote:
| The article is specifically about _Linux_ system calls.
| krackers wrote:
| If you're interested in more detail:
| https://0xax.gitbooks.io/linux-insides/content/SysCall/linux...
___________________________________________________________________
(page generated 2020-06-28 23:00 UTC)