5 ms·

Direct system calls are an amazing idea. The NtDll and bsd models are worse. The whole libc becomes a security boundary without the protection of kernel space.

Direct system calls are an amazing idea. The NtDll and bsd models are worse. The whole libc becomes a security boundary without the protection of kernel space. So much windows malware and process tampering happens because now you have a library (ntdll) fully in userspace that is given special privileges, which now becomes a huge attack surface. Then you have to deal with breakages between the built in libc versions and the kernel This syscall overhead isn't as much as you suppose it is; for workloads where the syscall overhead actually makes a difference there are robust low-syscall paths for io/latency sensitive operations with DPDK, io_uring, and futex being a few examples. And there are robust performant methods on linux for syscall interception/tracing, see seccomp unotify, bpf tracepoints, ftrace.

eqvinox 4mo ago
Your argument about libc/ntdll having "special privileges" is a bit weird in that the alternate option is everything having those privileges. The ntdll tampering doesn't exist on Linux because it's not necessary. It's not better due to this.
- matheusmoreira 4mo ago
  Yeah. On Linux it's just an optimization. What user space really wanted was a way to memory map some kernel data into the process address space in order to avoid switching to kernel mode while accessing it. Instead Linux memory mapped an entire ELF whose only purpose is to wrap the data. Newer system calls like io_uring are doing it right.
  - eqvinox 4mo ago
    Strongly disagree that providing the vDSO in ELF file format is somehow harmful or inefficient. You'll need a compatibility mechanism in any case since the exposed features will change over time, and doing that through normal symbol resolution avoids a whole bunch of extra effort. And after ld.so is done with relations on executable startup, it makes no difference in performance either. Look at the Linux architectures that have a vDSO in non-ELF format. It's seriously ugly. (I don't think the comparison with io_uring is valid either, very different kind of API.)
    - quotemstr 4mo ago
      Well, no more harmful or inefficient than ELF itself. :-) I really wish we'd ended up with PE or something with a two-level namespace. And yeah, nothing wrong with using ELF for the vDSO. People have strange intuitions about what's expensive and what's cheap.
    - matheusmoreira 3mo ago
      > harmful or inefficient It's not harmful, it just requires a lot of machinery. The normal system call entry point is perfectly simple, minimal, sufficient and language agnostic. As for inefficient, program startup speed matters. It's probably not contributing much to the overall profile but it's still parsing binary formats and looking up strings in hash tables. This is definitely stuff that could be eliminated entirely. Code could conceivably mmap a gettimeofday buffer later on when it actually needs it instead of doing it on the startup procedure of every single process. Only reason it's not done this way is history. > You'll need a compatibility mechanism in any case since the exposed features will change over time Not really. Existing system calls stay as is. Linux won't break them, they remain supported. New users will use the latest version of the system call. > And after ld.so is done with relations on executable startup Assumes that there is an ld.so. It's a completely optional component. The system should be usable without it. > Look at the Linux architectures that have a vDSO in non-ELF format. It's seriously ugly. We agree on this. I have no objection to the ELF format. If a vDSO must be provided, then ELF is a good a format for it. My point is that providing the vDSO should not actually be necessary, and that no system call should be forced to go through it. > I don't think the comparison with io_uring is valid either, very different kind of API Why? Both involve kernel/userspace shared memory. The difference is the vDSO hides the memory behind a function call while io_uring gives you the parameters you can pass to mmap to control it yourself, no ELF needed.
      - eqvinox 3mo ago
        > Why? Both involve kernel/userspace shared memory. The vDSO linking happens once, at startup. io_uring is a continuous service. With this fundamental of a difference in perspective between us I don't think it's useful to sink further time into this discussion thread.

eqvinox 4mo ago

Your argument about libc/ntdll having "special privileges" is a bit weird in that the alternate option is everything having those privileges. The ntdll tampering doesn't exist on Linux because it's not necessary. It's not better due to this.

matheusmoreira 4mo ago
Yeah. On Linux it's just an optimization. What user space really wanted was a way to memory map some kernel data into the process address space in order to avoid switching to kernel mode while accessing it. Instead Linux memory mapped an entire ELF whose only purpose is to wrap the data. Newer system calls like io_uring are doing it right.
- eqvinox 4mo ago
  Strongly disagree that providing the vDSO in ELF file format is somehow harmful or inefficient. You'll need a compatibility mechanism in any case since the exposed features will change over time, and doing that through normal symbol resolution avoids a whole bunch of extra effort. And after ld.so is done with relations on executable startup, it makes no difference in performance either. Look at the Linux architectures that have a vDSO in non-ELF format. It's seriously ugly. (I don't think the comparison with io_uring is valid either, very different kind of API.)
  - quotemstr 4mo ago
    Well, no more harmful or inefficient than ELF itself. :-) I really wish we'd ended up with PE or something with a two-level namespace. And yeah, nothing wrong with using ELF for the vDSO. People have strange intuitions about what's expensive and what's cheap.
  - matheusmoreira 3mo ago
    > harmful or inefficient It's not harmful, it just requires a lot of machinery. The normal system call entry point is perfectly simple, minimal, sufficient and language agnostic. As for inefficient, program startup speed matters. It's probably not contributing much to the overall profile but it's still parsing binary formats and looking up strings in hash tables. This is definitely stuff that could be eliminated entirely. Code could conceivably mmap a gettimeofday buffer later on when it actually needs it instead of doing it on the startup procedure of every single process. Only reason it's not done this way is history. > You'll need a compatibility mechanism in any case since the exposed features will change over time Not really. Existing system calls stay as is. Linux won't break them, they remain supported. New users will use the latest version of the system call. > And after ld.so is done with relations on executable startup Assumes that there is an ld.so. It's a completely optional component. The system should be usable without it. > Look at the Linux architectures that have a vDSO in non-ELF format. It's seriously ugly. We agree on this. I have no objection to the ELF format. If a vDSO must be provided, then ELF is a good a format for it. My point is that providing the vDSO should not actually be necessary, and that no system call should be forced to go through it. > I don't think the comparison with io_uring is valid either, very different kind of API Why? Both involve kernel/userspace shared memory. The difference is the vDSO hides the memory behind a function call while io_uring gives you the parameters you can pass to mmap to control it yourself, no ELF needed.
    - eqvinox 3mo ago
      > Why? Both involve kernel/userspace shared memory. The vDSO linking happens once, at startup. io_uring is a continuous service. With this fundamental of a difference in perspective between us I don't think it's useful to sink further time into this discussion thread.