[nickpsecurity]

What I'm saying is simple: there's the security of the code and the mitigation itself to consider. I know of no talented people interested in devrloping bypasses for OpenBSD mitigations since nobody uses OpenBSD. So, they break even more clever stuff in Chrome, Windows, etc. Given your example, lets change the mitigation to make it more obvious, though.

OpenSMTPD (email for short) is the target. Default are Windows, Linux, and OpenBSD on x86. OpenBSD devises a mitigation: use SPARC processor since x86 malware cant work. As you say, the malware works on everything but the SPARC box. You and others claim it means the mitigation is secure and so is what uses it.

Now, some guy named Nick claims it's no more secure than a BSD/Linux 0-day on x86: they just didn't target exploit for that environment. Sure, they have to learn SPARC ISA and how OBSD uses it. Sure there's work involved. Similar mitigations were beaten in the past by first person willing to invest effort, though. So, Nick posits reason SPARC is safe from x86 malware coders is that they don't care enough to deal with SPARC boxes. Maybe no market share.

See how that works now?

[digi_owl]

Whats the term, security by obscurity?

[nickpsecurity]

Basically. Now, it's fine to throw in obscurity or unusual mechanisms on top of good security practices. I used that to stop high-strength attackers before. Yet, we must be careful to note the difference between these mitigation results:

A. We stopped those vulnerabilities from working because nobody can bypass this mitigation.

B. We stopped those vulnerabilities from working because very little talent is working on beating our mitigation.

World of difference there as Chrome and SFI/CFI teams I linked up above found out when smart hackers and braniacs from CompSci began convergjng on their work. And shredding it.

Code-Pointer Integrity was last one standing after first round of peer review. I'll use it for medium-assurance if it survives 2-3 more. Check it out.