3 ms·

Any good resources/deeper dives into the details of what actually happens on modern computers when making these syscalls on, say, linux? I might have a reasonab

by vvern 3y ago

Any good resources/deeper dives into the details of what actually happens on modern computers when making these syscalls on, say, linux? I might have a reasonable idea about what goes on when performing a mode switch or context switch, but I’d love to have a reference or a nice walkthrough.

deleted 3y ago
[deleted]
mindwok 3y ago
My introduction to this was the 'Direct Execution' chapter of the book 'Operating Systems: Three Easy Pieces'. It's a fantastic write up on not just how system calls work, but the motivation behind why operating systems even implement them in the first place. It's not specifically about Linux, but the book is clearly heavily inspired by early *nix designs and it's still applicable. You can read it for free here: https://pages.cs.wisc.edu/~remzi/OSTEP/cpu-mechanisms.pdf https://pages.cs.wisc.edu/~remzi/OSTEP/cpu-mechanisms.pdf
cyberax 3y ago
This one is pretty good: https://blog.packagecloud.io/the-definitive-guide-to-linux-system-calls/ https://blog.packagecloud.io/the-definitive-guide-to-linux-s...
- matheusmoreira 3y ago
  > It’s not a great idea to call system calls by writing your own assembly code. > One big reason for this is that some system calls have additional code that runs in glibc before or after the system call runs. That's not really the fault of the system calls. The problem is the C library itself. It's too stateful, it's full of global data and action at a distance. If you use certain system calls, you invalidate its countless assumptions and invariants, essentially pulling the rug from under it. I've found programming in freestanding C with Linux system calls and no libc to be a very rewarding experience. Getting rid of libc and its legacy vastly improves C as a language. The Linux system call interface is quite clean. Don't even have to deal with the nonsense that is the errno variable.
  - PaulDavisThe1st 3y ago
    Sounds roughly equivalent to discussing how much more rewarding it is to walk 1000km than to drive it. Yes, everybody knows you can get from A to B on foot. But for multiple reasons, and over and extended period of time, we developed other methods of doing so. That doesn't invalidate the experience of doing it on foot, but it does make the walk into a very conscious choice that probably isn't the one most people are going to make most of the time.
    - vacuity 3y ago
      But the internal details of libc leaking is accidental, not essential, complexity for the problem at hand. There's the baseline level of difficulty with writing assembly language, but the libc influence is imposed on top of that.
      - PaulDavisThe1st 3y ago
        The internal details of libc are not leaking in the case under discussion. libc wraps system calls. If you use libc and try to make your own system calls, you're going to collide with internal details of libc. Not using libc is fine. Not making your own system calls via asm is fine. Pick one.
        vacuity 3y ago
        If the policy of the OS is to for programmers to only use libc for syscalls, perhaps that's a valid caveat to asm syscalls, but I don't think Linux is such an OS.
        matheusmoreira 3y ago
        > I don't think Linux is such an OS. It's not! I wrote somewhat at length about that very question in this article: https://www.matheusmoreira.com/articles/linux-system-calls https://www.matheusmoreira.com/articles/linux-system-calls
        3y ago
matheusmoreira 3y ago
I wrote an article about Linux system calls, albeit from the user's perspective, detailing why you might want to use them and how to do so. https://www.matheusmoreira.com/articles/linux-system-calls https://www.matheusmoreira.com/articles/linux-system-calls LWN has the kernel's perspective well covered by their articles on the anatomy of Linux system calls: https://lwn.net/Articles/604287/ https://lwn.net/Articles/604287/ https://lwn.net/Articles/604515/ https://lwn.net/Articles/604515/ https://lwn.net/Articles/604406/ https://lwn.net/Articles/604406/ They are thoroughly dissected in these articles. I also use them as a reference.
rzezeski 3y ago
I wrote a detailed walk-through of the illumos syscall handler back in 2016. It's missing the updates around KPTI (meltdown mitigation), but other than that the mechanisms should be unchanged. https://zinascii.com/2016/the-illumos-syscall-handler.html https://zinascii.com/2016/the-illumos-syscall-handler.html

by vvern 3y ago

deleted 3y ago

[deleted]

mindwok 3y ago

My introduction to this was the 'Direct Execution' chapter of the book 'Operating Systems: Three Easy Pieces'. It's a fantastic write up on not just how system calls work, but the motivation behind why operating systems even implement them in the first place. It's not specifically about Linux, but the book is clearly heavily inspired by early *nix designs and it's still applicable. You can read it for free here: https://pages.cs.wisc.edu/~remzi/OSTEP/cpu-mechanisms.pdf https://pages.cs.wisc.edu/~remzi/OSTEP/cpu-mechanisms.pdf

cyberax 3y ago

This one is pretty good: https://blog.packagecloud.io/the-definitive-guide-to-linux-system-calls/ https://blog.packagecloud.io/the-definitive-guide-to-linux-s...

matheusmoreira 3y ago
> It’s not a great idea to call system calls by writing your own assembly code. > One big reason for this is that some system calls have additional code that runs in glibc before or after the system call runs. That's not really the fault of the system calls. The problem is the C library itself. It's too stateful, it's full of global data and action at a distance. If you use certain system calls, you invalidate its countless assumptions and invariants, essentially pulling the rug from under it. I've found programming in freestanding C with Linux system calls and no libc to be a very rewarding experience. Getting rid of libc and its legacy vastly improves C as a language. The Linux system call interface is quite clean. Don't even have to deal with the nonsense that is the errno variable.
- PaulDavisThe1st 3y ago
  Sounds roughly equivalent to discussing how much more rewarding it is to walk 1000km than to drive it. Yes, everybody knows you can get from A to B on foot. But for multiple reasons, and over and extended period of time, we developed other methods of doing so. That doesn't invalidate the experience of doing it on foot, but it does make the walk into a very conscious choice that probably isn't the one most people are going to make most of the time.
  - vacuity 3y ago
    But the internal details of libc leaking is accidental, not essential, complexity for the problem at hand. There's the baseline level of difficulty with writing assembly language, but the libc influence is imposed on top of that.
    - PaulDavisThe1st 3y ago
      The internal details of libc are not leaking in the case under discussion. libc wraps system calls. If you use libc and try to make your own system calls, you're going to collide with internal details of libc. Not using libc is fine. Not making your own system calls via asm is fine. Pick one.
      - vacuity 3y ago
        If the policy of the OS is to for programmers to only use libc for syscalls, perhaps that's a valid caveat to asm syscalls, but I don't think Linux is such an OS.
        matheusmoreira 3y ago
        > I don't think Linux is such an OS. It's not! I wrote somewhat at length about that very question in this article: https://www.matheusmoreira.com/articles/linux-system-calls https://www.matheusmoreira.com/articles/linux-system-calls
        3y ago

matheusmoreira 3y ago

I wrote an article about Linux system calls, albeit from the user's perspective, detailing why you might want to use them and how to do so. https://www.matheusmoreira.com/articles/linux-system-calls https://www.matheusmoreira.com/articles/linux-system-calls LWN has the kernel's perspective well covered by their articles on the anatomy of Linux system calls: https://lwn.net/Articles/604287/ https://lwn.net/Articles/604287/ https://lwn.net/Articles/604515/ https://lwn.net/Articles/604515/ https://lwn.net/Articles/604406/ https://lwn.net/Articles/604406/ They are thoroughly dissected in these articles. I also use them as a reference.

rzezeski 3y ago

I wrote a detailed walk-through of the illumos syscall handler back in 2016. It's missing the updates around KPTI (meltdown mitigation), but other than that the mechanisms should be unchanged. https://zinascii.com/2016/the-illumos-syscall-handler.html https://zinascii.com/2016/the-illumos-syscall-handler.html