[nanolith]

This site is often fairly balanced, but I think the author often jumps to conclusions. The pinsyscall feature is one place where many security researchers have jumped to conclusions, because they only see it from their narrow x86 oriented view.

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.

[brynet]

> ARM64 has execute-only support so that it's possible for code to execute, but not read, a text segment.

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)

[alberth]

Since you're clearly knowledgable ...

What's your take on http://cheribsd.org (and CHERI as a concept overall)?

[nanolith]

I've been following CHERI for years. I'm a fan of runtime mitigations in hardware, better process isolation, and capability models. This couples nicely with an obsession of mine, which is the integration of formal methods into system and firmware development.

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.

[pjmlp]

While it might have inspired innovation, there is SPARC ADI that predates it, with Apple's PAC, Microsoft's Pluton, and ARM's MTE already being deployed on some systems.

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.

[nanolith]

At this point, I think that Intel and AMD have designed processors that are hostile toward security and process isolation. The amount of work required by an OS designer to work around the default insecure and leaky behavior of these processors is staggering. Worse, there is always the temptation to optimize performance by turning off these mitigations.

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.

[pstuart]

Would the evolutionary approach be an advantage in allowing existing code bases to run with minimal modifications? So not perfect but safer than linux with minimal effort?

[nanolith]

I think that it's difficult to quantify whether X is safer than Y. Instead, we should look at what safety measures X or Y have in place, and whether these can be reasonably improved. Certainly, a single comment on a forum would do this topic a disservice.

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.