OpenBSD 7.5

Original Article ↗ Hacker News Discussion ↗

OpenBSD 7.5’s release prompts renewed interest in its security-focused design, notably the new `pinsyscalls(2)` mechanism that encourages routing system calls through libc rather than allowing raw syscall ABIs, and in how this affects languages like Go and Rust. Commenters debate whether libc should be the primary user–kernel interface versus direct syscalls as on Linux, with broader comparisons of OpenBSD’s incremental, defense-in-depth approach to security against MAC-based models like SELinux or AppArmor. The thread also touches on filesystem choices, performance trade-offs, real-world deployment in areas like networking and firewalls, and the project’s distinctive culture, from LibreSSL to its release artwork and songs.

Go, Rust, libc, and syscalls

  • Discussion around OpenBSD 7.5’s removal of generic syscall() and move to pinsyscalls(); Go and Perl were converted to use libc wrappers.
  • Some Go users initially hit build/runtime issues on -current but resolved them after updating and reinstalling Go; conversions were done “months ago”.
  • Debate over whether languages should call raw syscalls or rely on libc:
    • One side: on Linux, stable syscall ABI makes libc unnecessary; each language could build directly on syscalls.
    • Other side: ossifying syscall ABI is harmful; libc as the facade allows kernel evolution and security hardening while preserving userland.
  • Rust’s rustix and projects like mustang, and Zig’s libc-free stdlib, are cited as examples of syscall-centric designs.
  • Counterarguments stress benefits of libc for interop (pthreads, NSS, malloc) and that FFI to libc is not materially worse than FFI to syscalls.

pinsyscalls(2) and security model

  • pinsyscalls() lets a process restrict syscalls to a specific text segment, encouraging use of libc and enabling defenses like execute-only code and immutable text segments.
  • Some security commentators are skeptical of its real-world impact; others see it as low-cost defense in depth, especially combined with ASLR and xonly mappings.
  • Clarified that it’s opt-in: if you don’t request it, you can still make raw syscalls.

OpenBSD vs Linux security

  • Linked critiques argue OpenBSD lacks MAC frameworks like SELinux/AppArmor and trails hardened Linux in some mitigations.
  • Others counter that pledge/unveil provide in-API confinement, and that few people demonstrate working exploits bypassing OpenBSD’s layers.
  • View expressed that overall “which is more secure” is hard to quantify; OpenBSD emphasizes evolutionary hardening and secure-by-default, but proper configuration matters on any OS.

Filesystems: FFS2, xattrs, and alternatives

  • Question about reintroducing extended attributes in FFS2: responses suggest “no plans”; FFS made 64-bit (timestamps/block numbers) and soft updates were removed as old/complex.
  • Some argue unveil/pledge reduce need for xattrs; others note they are unrelated and that xattrs are used for things like Samba metadata.
  • Interest in more modern filesystems (XFS, HAMMER2); a HAMMER2 port exists but appears stalled.

Ecosystem, governance, and culture

  • Clarification that OpenBSD is not a one-person project; many files have individual copyrights. The site/release page copyright reflects site/artwork/packaging.
  • Some praise the “single cohesive OS” model (kernel + userland shipped together) compared to mix-and-match Linux distributions.
  • Concerns raised about any benevolent-dictator model lacking clear succession, but also claims this structure resists corporate capture.
  • LibreSSL is noted as heavily worked on; at least one major vendor ships it.
  • Comments appreciate the ease of upgrading (sysupgrade; sysmerge; pkg_add -u) and the traditional release art/songs; new artwork is read as an Ozymandias reference.