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.

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.

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.

> Users of syscall(2), such as Perl and the Go programming language were converted to use the libc functions.

I think the following may still need to be converted:

  * unix.Pledge from golang.org/x/sys/unix
  * unix.Unveil from golang.org/x/sys/unix
  * terminal.ReadPassword from golang.org/x/crypto/ssh/terminal

On Linux, using direct syscalls is a good idea, since it's the stable userspace-kernel interface. There's really no need for libc on Linux, each language should just implement it's standard library on top of syscalls.

They didn't "get burned" they were "trying to provide a nice feature that wasn't as broadly compatible as they had hoped."

Its not always not so clearcut. For example using pthreads instead of just calling clone can be useful for interop etc. Similarly, anything involving NSS is probably best done through libc. Having libc malloc integrated makes interacting with other C libs easier. And so on.

After tedu's comment here I installed 7.5 in a VM and could build and run my Go software in it successfully, so I figured there were some Go build or config files or something somewhere getting in the way. I pkg_delete'd go, removed every Go build/config file I could find, and re-added Go with pkg_add. Now I can build apps with the previously mentioned modules; everything works fine now.

Thank you for the responses. :-)

I'm finding it quite difficult to compare OS "security" these days, whatever that means. Everyone seems to have their own crackpot opinions. If anyone with a security background could chime in, I'd be forever grateful.

Isn't that pledge?

And in general, I observe that lots of people are happy to say that OpenBSD's protections are no good, but somehow they can't be bothered to actually show a working exploit.

Pledge/unveil are APIs that developers use to directly restrict what an app can do/can't do.

Would this have mattered/stopped/mitigated the `xz` problem if systemd spawns opensshd and transiently loads infected .so shared objects?

Or for a more standard/modern FS like XFS (I don't expect OpenBSD to go for ZFS bloat).

At some point, I think I heard that they might use HAMMER2, which would be nice.

With unveil(2) and maybe pledge(2), I do not think there is a need for Extended Attributes. To me, all it does is add complexities not really needed in OpenBSD.

In short no. Also they removed softupdates, code was old and slow and was holding back the quest to unlock.

What does this mean? 64-bit inode numbers? 64-bit timestamps? Something else?

> Also they removed softupdates,

Shame in a way, I remember reading McKusick's paper and being impressed. But I guess it's the antithesis of batching, which turned out to be more important for performance than avoiding the extra I/O due to journalling. Also the implementation was AFAIU fearsomely subtle and tricky.

What's that supposed to mean? ed is the standard text editor, yet we don't actually expect anyone to use it (let alone know it...)

I used to heard that OpenBSD was often used as Internet facing middlebox (like firewalls/proxy/network load balancer) because of how good pf and relayd are.

But it would surprise me if it would still be the case nowadays, OpenBSD seems to perform poorly [2] in terms of network throughput compared to the competition (VyOS/VPP). And I don't think this 7.5 upgrade helped a lot regarding this topic.

[1]: https://gregsowell.com/?p=7069 [2]: https://ipng.ch/s/articles/2021/07/19/pcengines-apu6.html

Caught my eye. I'm vaguely aware that Theo de Raadt is not the paragon of modesty, but would still expect a more "communal" copyright. Or is OpenBSD largely a one-man show?

https://marc.info/?l=openbsd-announce&m=171228270018970&w=2

You will also find separate copyright statements in a lot of the source files and many carry the name of their authors.

perhaps Theo has a plan for an eventual succession, perhaps not. Sometimes dictators can't really conceive of somebody else running the show so they don't plan for it.

In particular, kernel ABI is the main stable interface that Linux exposes - and all applications can just use syscalls directly without having to interface with the libc at all. However, that means that kernel must not change its ABI lest it risks breaking compatibility, and each functionality that isn't implemented inside of the kernel (e.g. GUI stuff) cannot be implemented completely portably.

However, using pinsyscalls(), a kernel can make sure that syscalls can only be called from the libc - therefore, making the libc de-facto ABI! Which allows for much more freedom in changing kernel ABI, as long as the libc follows through. Perhaps this way the system can go away from the syscall-level ABI and move over to the libc ABI / shared library ABI?

It only became something else, when C got standardised, a tiny subset of it landed into ISO C, grew beyond UNIX, and the rest of the UNIX API surface landed at Open Group's POSIX.

Obviously on the UNIX world nothing changed, until GNU/Linux came into scene and decided to act in another way, due to being GNU ecosystem + Linux kernel combo.

Linux has successfully paved the way and demonstrated its practicality. Yes, it made certain unfortunate mistakes along the way, but OpenBSD (or any other OS) can learn from those and provide a better solution.

If you mean a C based OS ABI, there are many other alternatives, like on managed OSes, IBM and Unisys surviving mainframe and micro computers, OS IPC like COM/XPC/AIDL/FIDL/D-BUS.

Nobody seems to understand how this feature works, even though it's quite simple. The process asks the kernel to only allow system calls from one segment. If you don't like that, don't ask for it.

Calling into system calls in libc is not a hindrance at all for the use of other languages, any more than calling directly into a syscall would be. Cross-language function calls have been a time honored tradition since the first compilers were developed.

Linux's ossified syscall ABI is a quirk of Linux, and not a feature found in most, let alone many, operating systems.

And FFS, Ive been using OpenBSD for well over 2 decades now. I'd say any syscall changes done in the OS are minimal compared to eg. linux.

Says who? I certainly wouldn't consider Linux's syscall ABI to be well designed. You know what is well designed? A stable facade that provides minimal overhead between two components, which prevents tight coupling. Like libc.

> You can obviously extend on it and deprecate at your will.

Only by breaking userland, which grinds this process to a crawl, even when it can happen at all. libc provides a better interface here.

> Thing is, call gates are quite more common now

I fail to see the relevance here. The mechanism by which syscalls are made doesn't make it cheaper to ossify your syscall ABI, nor does it improve security. It can certainly reduce the performance hit of a context switch. But, even with call gates, the overhead of a context switch is so high that adding the overhead of calling a wrapped function in libc is hardly going to matter.

> and there is quite some effort into of runtime linking vs static linking

What effort? Yeah, you have ld.so doing the relocation for you at runtime, but this happens once at program load time. Compared to everything else that must occur to load a program, dynamic linking adds minimal overhead.

> In my opinion, libc should not be a broker for privileged operations.

That's an interesting opinion, but beyond an unlisted "plethora of reasons", I don't see any relevant reason for this blanket ban. Having a single path into and out of the system call interface provides a way in which userland protections -- such as syscall pinning, immutable pages, etc., can be added. For defense in depth, this is useful.

> but the most obvious is that languages may not use libc in their linkage.

How does language runtime library linkage matter? What is the real difference to a language whether it calls read() or the read syscall? Either way, it has to marshal arguments through a FFI. Either way, it has to do the same amount of work. Languages must be ported to each operating system they run on. On OpenBSD and MacOS in particular, this porting means calling libc. On most OSes, libc is considered the preferred interface. On Linux, it's not, and because of that, folks assume that Linux's relative uniqueness here is somehow the default.

There is really no point to directly using syscalls. In nearly every case for unistd, socket, and fcntl, the libc wrapper is negligible. You can do all of the same things. There are few, if any, enforced C-isms. Even where they exist, they can be abstracted with a middling to average FFI library. Performance-wise, the significant overhead is making the syscall. Calling a library to do this has little measurable effect.

This is much ado about nothing.

OpenBSD has spent a lot of time sanitizing their libc implementation, and they have even split their static C runtime library to further reduce its footprint.

Developers are only really penalized for what they use. read, write, socket, bind, close, open, mmap, etc., really aren't that complex. Already, that's a significant portion of the libc footprint that any other language would use.

I personally see little reason why libc couldn't be further minimized into a libunix that just contained the syscall interface. It doesn't make much of a difference really, but perhaps it would shift the largely misplaced unease that many developers have regarding anything involving C.