> Either the attacker has arbitrary code execution [...] or they don’t.
That's beyond reductive, even if we grant this website's fundamental premise which rejects economic cost analysis in threat mitigation. Many of the articles on this website are like that--1) it's possible (and even inevitable with sufficient effort) to circumvent mitigation X, therefore 2) mitigation X has no value. That's a huge logical leap that the author (authors?) often cover up with, "Trust me, I develop exploits".
EDIT: In case the post is changed, the full quote is, "Either the attacker has arbitrary code execution, and can ROP their way to the 'SPECIFIC execve entry point', or they don't."
What attack _would_ be able to get past all the existing mitigations (XOM, random relinking + ASLR, msyscall) and be able to find a single existing syscall instruction but not a particular libc function entrypoint instead?
I could kind of see the value of this if the above mitigations didn't exist, but as far as I'm aware, they're already pervasive on OpenBSD.
The same basic argument was made about msyscall, relinking, etc. Anyone who accepted the basic argument would have dismissed many of those other mitigations out-of-hand as well.
AFAIU (based on my recollection of some tech@ posts over the past few years), Theo has been studying recent papers on exploit techniques. The purpose of pinsyscall is to address some of the weaker areas in all of these layers of mitigations. Is the benefit narrowly constrained to some specific scenarios? Yes, but that's beside the point.
Moreover, there are beneficial side-effects from this kind of work. By narrowing the license that applications can take regarding assumptions about how the runtime operates, it becomes increasingly easier over time to implement much more strict mitigations or outright solutions. That site often derides OpenBSD mitigations by pointing out technically superior mitigations from grsecurity, various research patches to LLVM, etc. But from a practical security engineering standpoint, that's comparing apples and oranges. OpenBSD sometimes makes compromises so that they can actually ship--by default and comprehensively--these mitigations.
Security is a process, not a product. Analyzing every mitigation or technique in isolation is missing the forest for the trees. Not only does it matter how mitigations work in tandem, but the process of exploration and application matters, too, perhaps even more so.
