4 ms·

That Linux table is quite a bit out-of-date -- it's at least older than Linux 3.14 (2014) based on sched_setattr's absence from the list. [1] is a much more mod

by cyphar 6y ago

That Linux table is quite a bit out-of-date -- it's at least older than Linux 3.14 (2014) based on sched_setattr's absence from the list. [1] is a much more modern table (and is updated more frequently), but it's probably simpler to just look at the actual syscall table[2]. On x86_64, there are currently 401 syscalls (syscall numbers 387 through 423 are reserved and 436 is used by a syscall not-yet-merged). [1]: https://fedora.juszkiewicz.com.pl/syscalls.html https://fedora.juszkiewicz.com.pl/syscalls.html [2]: https://elixir.bootlin.com/linux/latest/source/arch/x86/entry/syscalls/syscall_64.tbl https://elixir.bootlin.com/linux/latest/source/arch/x86/entr...

EdSchouten 6y ago
Thanks for the correction! It confirms that Linux’s system list is by no means ‘out of control’.
- snvzz 6y ago
  If 400+ syscalls doesn't scream out of control to you, I doubt I can convince you.
  - ajross 6y ago
    Again, there is nothing special about a "system call", it's one of MANY entry points into the kernel. Counting them in isolation means nothing. And, again, Linux has historically been very careful to resist arbitrary subsystem-specific bloat in syscall variety. Almost all of its new kernel-exposed functionality uses other mechanisms (e.g. sysfs, new filesystems like cgroup, etc...) which are more auditable and amenable to userspace-managed authorization via stuff like filesystem permissions, chroot and containers. And of course, as with everything else, virtually all this new functionality is modular. Don't want the system call (or whatever)? Don't put it in your kernel. Basically: you're wrong here. Cite the specific functionality you think is being shipped in an insecure way.
    - snvzz 6y ago
      >it's one of MANY entry points Just because the kernel does things wrong all over the place, it doesn't mean having too many syscalls specifically is not itself wrong. >Cite the specific functionality you think is being shipped in an insecure way. The whole Linux kernel. Complexity in privileged code is cancer. For an example of how to do a kernel properly, refer to seL4[0]. [0]: https://sel4.systems/About/seL4-whitepaper.pdf https://sel4.systems/About/seL4-whitepaper.pdf

by cyphar 6y ago

EdSchouten 6y ago

Thanks for the correction! It confirms that Linux’s system list is by no means ‘out of control’.

snvzz 6y ago
If 400+ syscalls doesn't scream out of control to you, I doubt I can convince you.
- ajross 6y ago
  Again, there is nothing special about a "system call", it's one of MANY entry points into the kernel. Counting them in isolation means nothing. And, again, Linux has historically been very careful to resist arbitrary subsystem-specific bloat in syscall variety. Almost all of its new kernel-exposed functionality uses other mechanisms (e.g. sysfs, new filesystems like cgroup, etc...) which are more auditable and amenable to userspace-managed authorization via stuff like filesystem permissions, chroot and containers. And of course, as with everything else, virtually all this new functionality is modular. Don't want the system call (or whatever)? Don't put it in your kernel. Basically: you're wrong here. Cite the specific functionality you think is being shipped in an insecure way.
  - snvzz 6y ago
    >it's one of MANY entry points Just because the kernel does things wrong all over the place, it doesn't mean having too many syscalls specifically is not itself wrong. >Cite the specific functionality you think is being shipped in an insecure way. The whole Linux kernel. Complexity in privileged code is cancer. For an example of how to do a kernel properly, refer to seL4[0]. [0]: https://sel4.systems/About/seL4-whitepaper.pdf https://sel4.systems/About/seL4-whitepaper.pdf