BSD = kernel + userland
It's much simpler than you represent.
There are only 4 real trees here:
* FreeBSD
* NetBSD
* OpenBSD
* Dragonfly BSD
In very approximate order, and I suspect that there are (wild approximation) half as many users for each step down the list.
One estimate I've seen is that there are ~7K users of openBSD, in total, worldwide.
There are a few distros of FreeBSD. None of the others have distros, AFAIK. PC-BSD was a FreeBSD distro. iXsystems acquired it, turned it into TrueOS, and then killed it 4Y ago.
Maybe it'll finally scratch the ultimate nerdy OS itch.
Probably not though.
Yeah, on x86, I can craft a ROP attack that allows me to discover relocations for functions fairly trivially, especially for coarse ASLR, because I can read the text segment. But, ARM64 has execute-only support so that it's possible for code to execute, but not read, a text segment. In this situation, pinsyscall does add a valid defense in depth layer. It's still imperfect, but this does in fact raise the bar necessary to carry out a ROP attack when combined with randomized re-linking on boot ASLR. Further, once dynamic linking has occurred, the text segment for a binary is made immutable so that no mapping changes can occur, including mmap.
I think that OpenBSD still has a long way to go before all of these defenses align, but they are far less trivial than the author makes them out to be, because none of them are meant to be used alone. OpenBSD developer decisions like these can sometimes appear to be casting about randomly, because they are making small improvements instead of building toward a particular goal. Sometimes, they hit gold as with W^X, which was widely adopted. Sometimes, their ideas stink, like systrace. But, I don't think it's wise to just dismiss these ideas out of hand.
Instead, I recommend that people look to the history of OpenBSD, which has been more of an evolutionary approach to security instead of a revolutionary approach (i.e. Fuchsia). From an evolutionary perspective, pinsyscall makes sense as it is low-hanging fruit that can buy some security and can force applications to use a standard interface (libc) instead of making raw system calls. From a revolutionary perspective, pinsyscall just seems like a dead end. Revolutionary design has convergent effects -- all of the pieces come together in a perfectly engineered defensive shell. Evolutionary design has emergent effects -- fixes and features build on each other until they co-evolve into strong defenses.
OpenBSD does xonly by default on multiple architectures (arm64, risc-v, ... g5 powerpc), including even amd64 on recent Intel/AMD CPUs supporting MPK/PKU:
https://marc.info/?l=openbsd-cvs&m=167423045918820&w=2
On machines that lack hardware-enforcement, at least on CPUs that can differentiate between traps for instruction-fetch and data-fetch, there is still benefit:
https://marc.info/?l=openbsd-cvs&m=167517831914525&w=2 (msyscall(2) part is now handled by pinsyscalls in -current)
What's your take on http://cheribsd.org (and CHERI as a concept overall)?
That being said, CHERI has a long way to go before it makes it to any production system. ARM Morello has certainly breathed new life into it, as has its current push toward a RISC-V ISA. Going from R&D to synthesis on production hardware is a significant leap.
It has inspired innovation in hardware much as seL4 and similar projects have inspired innovation in the formal methods field. For that, I'm grateful.
Still looking forward to CHERI ideas to go mainstream though.
Only Intel and AMD keep messing up their attempts to hardware memory tagging, for several decades now, starting with iAPX 432.
Perhaps that's why I enjoy working on microcontrollers and firmware. Yeah, there are potential CPU attacks on these, but it's much easier to manage mitigations, and these mitigations don't come with steep performance penalty trade-offs.
OpenBSD has clearly been in the business of making small improvements with each release. This model has worked for them, but it has also been part of what makes them controversial. I trust OpenBSD for my personal servers and my travel laptop. I use it as a build target for my projects.
That being said, do I think that people should switch from Linux to OpenBSD? I wouldn't do this purely for security, because Linux has not been sitting still either. But, I think it's definitely a good idea to take lessons that OpenBSD has taught when configuring a Linux server: disable things you don't need, use the most aggressively secure options for services you provide, and add as much isolation between pieces that you can. Regardless of which OS you choose, you should spend time familiarizing yourself with what is required to harden the security for servers you make available with a public IP address.
OpenBSD's "secure by default" idea is great until you need to enable a service, which widens its attack surface. Doing this safely requires research and knowledge. In this way, I don't think that OpenBSD is much different than the average Linux distribution. I openly admit that I like OpenBSD, but I don't want to steer people the wrong way by claiming that they would be safer using it. In fact, blindly switching operating systems could make folks less safe, because they will probably use the new operating system incorrectly. Instead, study and experiment.
Also I think it shows value in having independent implementations of standards. If you have 5x different xz tools or C compilers or Javascript engines, the threat is chopped in half, plus you can easily compare reference outputs between them (RE: on trusting trust)
I'm not a security person but I also think a lot of malware damage comes from companies / users using misconfigured or outdated software. As such, if you were a sysadmin, knew what you were doing and had the time, then running GNU/Linux is probably fine, but I'm not super knowledgeable. I just want to host a website or run a tor-relay on a VPS and not have to worry about updating my system as soon as some 0-day is announced in glibc or systemd; even if it's in the service itself, my hope is that by using a non-mainstream OS the exploit might not initially target it, hence giving sufficient time to see the news somewhere and patch / update.