[tete]

> This brings us to OpenBSD's strategy for exploit mitigation, which is in my eyes has far too much tunnel vision

While I understand where that comes from, I'd argue that OpenBSD does both. There is quite a few more general approaches in the system.

In my opinion (which might be wrong, please disagree!) you need both, because one tends to have that issue that layers and layers of general mitigation are added, but when someone takes a look the issues tend to arise where the specific setup and general context is exploited which is harder to protect against.

There is a great talk that I can't find right now, that is about a company network that was pretty securely set up, but taking a look at the constellation (including specifications of standard protocols) is abused to still compromise it.

I am not sure if that's the best approach, but while I agree it's overall better to completely rule out a whole class of bugs/attacks go for it, however it's usually with exceptions which is why these these things are even still a topic.

[saagarjha]

I think OpenBSD has tunnel vision on the wrong part of an exploit. Like they'll read a blog post on how to construct a ROP chain and instead of figuring out how you might prevent someone from subverting control flow they look at the tool used to find gadgets and try to make that harder. Or if they see exploits that spray syscall instructions they will block them in JIT regions. The problem here is that these aren't actually the hard parts that need significant effort to change for an attacker, they're really just whatever happened to be convenient. You can do a very specific mitigation that e.g. hardens a problematic API but you really want to make sure an attacker goes "hmm, I am not really sure what I would do if you blocked this, I guess I'll have to think for a while about how I might even get started" versus "sigh, this is annoying, guess I need to try the other way that is a little more work".