3 ms·

Bah I read until the "FFI" section Yes, you must use "C" if you use the libc (seems obvious) However, you can issue your syscalls directly. Of course, to do

Bah I read until the "FFI" section Yes, you must use "C" if you use the libc (seems obvious) However, you can issue your syscalls directly. Of course, to do that, you will have to rewrite your own libc .. nothing is free. It shall be noted, however, that this is not possible in every environments: I believe that openbsd's code must use the system libc. At the same time, on windows, you must use the provided library. This does not mean the OS library is always C (but this means your new language must do FFI with whatever language is used by the system). Maybe only Linux allows anybody to issue syscalls directly ?

yencabulator 2y ago
One interesting angle on this is that with io_uring, you start using fewer glibc-functions-calling-syscalls, and more and more of your hot inner loop is about the data structures in the ringbuffers.
masklinn 2y ago
> Maybe only Linux allows anybody to issue syscalls directly ? That is correct. For the reason that Linux is a kernel, and glibc is a separate and independent project, so syscalls are the system interface on Linux. On other systems things range from syscalls being willfully broken on every update (windows) to syscalls being ABI-stable but removed unless compat-built (FreeBSD), in the middle you have e.g. MacOS which makes no guarantees and will break syscall ABI without warning (even if they’re generally stable) and OpenBSD trying to lock them down to static libc only to mitigate gadgets.
- deng 2y ago
  Windows also allows you to issue syscalls directly (meaning without using ntdll), but that'll usually get your process killed&quarantined by pretty much any anti-malware suite, as that's highly suspicious behavior. EDIT: You edited your post mentioning this, but I'll leave it here. :-)
  - masklinn 2y ago
    > Windows also allows you to issue syscalls directly Technically most systems do, OpenBSD is the only one I know of actively trying to prevent that. The line is rather whether there is support and maintenance for doing that aka how likely is it that your program will break on updates. For Windows, it’s virtually guaranteed because IIRC the syscall numbers are just the index of the syscall name in a big sorted table, so if any syscall gets added or removed the table gets offset and you get the wrong syscall.
    - deng 2y ago
      We fully agree: it's technically possible, but it's not practical and really only done by malware to skip the userland hooks set up by antivirus software.
esdf 2y ago
You can issue syscalls directly on Windows too but updates often change the syscall numbers so you never see them used legitimate software.
johannes1234321 2y ago
Even doing the sys all directly doesn't help much if the syscall is defined in terms of C types.
- masklinn 2y ago
  That’s by far the least issue, C types are not complicated even when they’re aggregates. The system calling conventions, both register and stack layout/ guarantees, are the major issue.

yencabulator 2y ago

One interesting angle on this is that with io_uring, you start using fewer glibc-functions-calling-syscalls, and more and more of your hot inner loop is about the data structures in the ringbuffers.

masklinn 2y ago

> Maybe only Linux allows anybody to issue syscalls directly ? That is correct. For the reason that Linux is a kernel, and glibc is a separate and independent project, so syscalls are the system interface on Linux. On other systems things range from syscalls being willfully broken on every update (windows) to syscalls being ABI-stable but removed unless compat-built (FreeBSD), in the middle you have e.g. MacOS which makes no guarantees and will break syscall ABI without warning (even if they’re generally stable) and OpenBSD trying to lock them down to static libc only to mitigate gadgets.

deng 2y ago
Windows also allows you to issue syscalls directly (meaning without using ntdll), but that'll usually get your process killed&quarantined by pretty much any anti-malware suite, as that's highly suspicious behavior. EDIT: You edited your post mentioning this, but I'll leave it here. :-)
- masklinn 2y ago
  > Windows also allows you to issue syscalls directly Technically most systems do, OpenBSD is the only one I know of actively trying to prevent that. The line is rather whether there is support and maintenance for doing that aka how likely is it that your program will break on updates. For Windows, it’s virtually guaranteed because IIRC the syscall numbers are just the index of the syscall name in a big sorted table, so if any syscall gets added or removed the table gets offset and you get the wrong syscall.
  - deng 2y ago
    We fully agree: it's technically possible, but it's not practical and really only done by malware to skip the userland hooks set up by antivirus software.

esdf 2y ago

You can issue syscalls directly on Windows too but updates often change the syscall numbers so you never see them used legitimate software.

johannes1234321 2y ago

Even doing the sys all directly doesn't help much if the syscall is defined in terms of C types.

masklinn 2y ago
That’s by far the least issue, C types are not complicated even when they’re aggregates. The system calling conventions, both register and stack layout/ guarantees, are the major issue.