Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Guide to Linux System Calls (2016)

blog.packagecloud.io

Post reply on HN
Print view View original

21–30 of 37 posts

Re: Guide to Linux System Calls (2016)

#21

Post by api »

yjftsjthsd-h wrote: post #9
ufo wrote: post #6

Earlier 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…

Windows has a libc? I often see windows binaries statically linked because otherwise you have to drag along all the DLLs.

Re: Guide to Linux System Calls (2016)

#22

Post by jmillikin »

khrbtxyz wrote: post #13
saagarjha wrote: post #10

Earlier quoted context omitted.

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

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.

https://john-millikin.com/unix-syscalls#darwin is a small, "hello world" example.

Re: Guide to Linux System Calls (2016)

#23

Post by saagarjha »

jmillikin wrote: post #22
khrbtxyz wrote: post #13

Earlier quoted context omitted.

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.

https://john-millikin.com/unix-syscalls#darwin is a small, "hello world" example.

> Note that I have left out the instructions to statically link binaries because they are documented as unsupported

That's a bit annoying, especially since you're already using raw syscall numbers anyways. Here's how to make it static:

  .intel_syntax noprefix
  
  #include 
  
  #define UNIX_SYSCALL 0x2000000
  
  .globl start
  start:
      mov rax, UNIX_SYSCALL | SYS_write
      mov rdi, 1
      lea rsi, text[rip]
      lea rdx, length
      syscall
      mov rax, UNIX_SYSCALL | SYS_exit
      xor rdi, rdi
      syscall
  
  text:
  .asciz "Hello, world!\n"
  .equ length, . - text
Compile that with clang -static -nostdlib.

Re: Guide to Linux System Calls (2016)

#24

Post by ChrisSD »

api wrote: post #21
yjftsjthsd-h wrote: post #9

Earlier quoted context omitted.

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…

Windows has a libc? I often see windows binaries statically linked because otherwise you have to drag along all the DLLs.

With Windows "libc" is split in two: ucrt and vcruntime

ucrt is available on all modern version of Windows (since 7) and doesn't need to be statically linked or distributed with the application. It has most functions needed for the c runtime and library.

vcruntime comes with Microsoft's C/C++ compiler. It has functions such as longjmp, memcpy, memset etc and C++ exception handlers. This does not come with Windows. It can be installed separately by the user or distributed with the application (either by placing it the same folder as the exe or by statically linking).

Re: Guide to Linux System Calls (2016)

#25

Post by cellularmitosis »

_y5hn wrote: post #2

I guess not many actually need to call linux kernel system calls directly bypassing proper measures, but how many fondly remembers int 21h?

The thing I don't like using language like "proper" is that it creates a frame of "good or bad", when in reality everything in tech is a trade-off, rather than "good or bad".

Re: Guide to Linux System Calls (2016)

#26

Post by jmillikin »

saagarjha wrote: post #23
jmillikin wrote: post #22

Earlier quoted context omitted.

https://john-millikin.com/unix-syscalls#darwin is a small, "hello world" example.

> Note that I have left out the instructions to statically link binaries because they are documented as unsupported That's a bit annoying, especially since you're already using raw syscall numbers anyways. Here's how to make it static: .intel_syntax noprefix #include #define UNIX_SYSCALL 0x2000000 .globl start start: mov rax, UNIX_SYSCALL | SYS_write mov rdi, 1 lea rsi, text[rip] lea rdx, length syscall mov rax, UNIX…

You don't have to change the source or compile with `clang` -- switching the LD command to:

  ld -arch x86_64 -o hello hello.o -macosx_version_min 10.8 -static -e _main
is sufficient if you're determined to violate the OS vendor's compatibility requirements.

Re: Guide to Linux System Calls (2016)

#27

Post by anaisbetts »

pjmlp wrote: post #11
yjftsjthsd-h wrote: post #9

Earlier quoted context omitted.

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…

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 (actu…

Yep, ntdll is the bottom of the stack. Raw syscall numbers are not guaranteed across Windows versions and in fact, can be changed by as something as small as a security update. They end up being generated automatically at build time, so there's no guarantee of any kind of stability.

Re: Guide to Linux System Calls (2016)

#30

Post by pjmlp »

monocasa wrote: post #16
pjmlp wrote: post #15

Earlier quoted context omitted.

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.

Most of ntdll.dll is officially sanctioned at this point. It's officially documented, and obviously plays into the backwards compat choices they make.

Not really, Windows Internals always refers to the few public ones as "take care when relying on this", very few entries do exist on MSDN or Technet, and those that do exist are mostly tailored for device drivers scenarios.
Post reply on HN