4 ms·
> 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
by 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 agoWindows 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 agoWe 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.