John Ioannidis (first name on the list… IPsec) passed away a few weeks ago and almost nobody noticed.
I attended a memorial on Zoom and people said he also created the building blocks that permitted Mobile IP (IP on your cell phone) to work.
In addition to work pioneering privdrop/privsep design for network daemons, and the almost ubiquitous adoption of pledge(2)/unveil(2) across the base system, I think people are missing out on much more recent mitigation work, such as mimmutable (which Linux is just beginning to land with mseal), on OpenBSD, most of a programs static address space (.text/ld.so's .text/.bss/main stack) is now automatically immutable.
There's also execute-only memory and BTI/IBT on modern Intel/AMD, and ARM machines, enabled by default. Including a significant amount of ports development work to make the larger software ecosystem ready for this.
A phenomenal resource on the same subject:
> Random-data memory: the ability to specify that a variable should be initialized at load time with random byte values (placed into a new ELF .openbsd.randomdata section) was implemented in OpenBSD 5.3 by Matthew Dempsky.
What's the use case for this?
EDIT: further down is one example:
> RETGUARD is a replacement for the stack-protector which uses a per-function random cookie (located in the read-only ELF .openbsd.randomdata section) to consistency-check the return address on the stack. Implemented for amd64 and arm64 by Todd Mortimer in OpenBSD 6.4, for mips64 in OpenBSD 6.7, and powerpc/powerpc64 in OpenBSD 6.9. amd64 system call stubs also protected in OpenBSD 7.3.
Really surprised that pledge / unveil isn't featured more prominently on this page.
Also a great resource:
Have they implemented ISO C11 _Thread_local yet? It's been the number one annoyanceÂą with porting software to OpenBSD. It is (was?) the only mainline OS without support for native thread-local storage.
Âą e.g. https://github.com/FRRouting/frr/blob/3f290c97e8325bd9db9363...
For those interested in actually supporting some of this work:
Incredible. I wonder what's the debugging experience for userland developers with all these security features enabled (especially the memory randomization ones).
Is OpenBSD suitable for daily use on a laptop?
Does anyone have such experience? Is it ok?
carp is one of my favorite things to come out of OpenBSD. It's awesome combined with HAProxy. I really enjoyed managing that system.
Thanks for posting this, I think in our industry provenance is an underrated piece of knowledge.
Position-Independent Executables (and ASLR) were used by AmigaOS back in 1985. It had to, since the Amiga lacked an MMU, and had very little memory, so anything that was loaded had to be placed at whatever ram was available.
It didn't need the executable to end up in a single block either, every individual section could end up in a different location. Compilers produced large numbers of sections to facilitate this process.
Big respect to OpenBSD. Now all it needs is a FS with ZFS's core capabilities and it'll be almost perfect.
A LOT of those innovations were first present in grsecurity/PaX. Back when it was freely available to everyone as well. I guess the arguments is the OpenBSD has them by default with needing a 3rd party patch, that's why they're claiming them as their innovations?
I am guaranteed to get grief on this but an anti-Innovation in OpenBSD (so obsessed it is about security) is to use an unsafe language like C everywhere in kernel and user space.
The implementation of OpenBSD predates many safer systems languages but I think OpenBSD should now start moving to a checked variant of C or a safer language like Rust/OCaml/Odin/Zig/Something else.
The conversion can start with some OpenBSD user space programs. I notice a steady stream of C related security fixes in the OpenBSD changelog. Many of these could have been probably avoided if the implementation language was more “safe” by default.
I doubt that this is going to happen but I think it is fair to point out that using C does give you some additional security headaches by default.
I wonder if we could get router based on OpenBSD.
W^X is only true in an extremely narrow sense. They said they were first, and that it cannot be done on x86. Which was a surprise to me, having run it on multiple Linux architectures, including x86, for years with PaX or grsec.
Then I guessed they looked around, and saw oh we can do it on x86 too, the pax way.
Does OpenBSD still have a giant lock?
Genuinely curious, and it’s been years since I’ve looked at it.
I am hopeful for got (game of trees).
OpenBSD still uses CVS, and I suspect its development will benefit greatly (actually accelerate) from the switch, once it eventually happens.
For someone who’s interested in getting into any *BSD, which should I go with? OpenBSD or FreeBSD?
> This is a list of software and ideas developed or maintained by the OpenBSD project
(Emphasis mine.)
Yet they can't manage a unified page cache like every other OS on the planet? I'll be more receptive to the concept of OpenBSD innovating when their virtual memory subsystem gets over Reagan leaving office.
* Best man pages ever
They forget to list The0's comebacks
It also leads the BSDs in RISC-V support.
Off topic: I'm wondering why OpenBSD pages (and many "*ux") just uses basic HTML with no styling or CSS?
Typography matters for readability. For the minimum get a decent line height and limit the line length to 60-ish characters.
Are OpenBSD not taking (potential) users seriously? User experience matters, and the readability of the docs is part of the UX.
(sorry for the rant)
wow, 25+ years later and ipv6 is still not fully integrated
Perhaps one day the OpenBSD folks will figure out how to completely prevent user programs from making syscalls. It seems they are mostly there but still not quite. Please don't mention WASM in your replies.
OpenBSD foundation raised around ~380 thousand IIRC.
By creating OpenSSH and the fact all fortune 500 companies use it, I would say every year, the foundation should be bringing in around 1 or 2 million. It is time these companies really give back.
And while I am here, hardware vendors should open up their source, looking directly an Nvidia.