[wahern]

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.