If memory safety issues are 75% of exploited zero days it sounds to me like they're the biggest issue in the ecosystem by far.

Unless your point is merely that average Joes write such terrible code that you don't even need memory safety issues to exploit their software, [citation needed]

Google says memory safety issues are 75% of exploited zero days. (https://security.googleblog.com/2024/10/safer-with-google-ad...)

I worked at Mozilla for a bit over six years and really enjoyed my time there. There were lots of brilliant people attracted by the mission and the work was technically interesting. I left in part because I came to the conclusion that the answer to these questions was no. Google's distribution advantages with Chrome and getting boxed out of mobile by the bundled Android/iOS browsers was simply too much to overcome by making a better product. People can gripe about Mozilla's management or product decisions all they want but the fundamental problem is the structure of the web browser market.

https://pmc.ncbi.nlm.nih.gov/articles/PMC10559184/#aoi230067...

Even without rseq(2) you're looking at a "different algorithm". For one, a proper userspace mutex allows the excluded threads to be descheduled and the core can be repurposed to run other tasks, rather than hammering away at the contended cache line.

EDIT: or maybe you're asking if introducing an explicit userspace mutex is better than a lockless algorithm with false sharing issues. The answer is that it's workload dependent but it definitely can be.

If you remove the 64 byte alignment (which forces each counter variable onto a separate cache line) from hitcounter-shard.c you ought to be able to see the performance difference for yourself.

There is a time-slice extension feature in the works that's roughly "please let me finish this critical section before you interrupt me". But a hard guarantee that userspace code won't be interrupted is probably untenable in a preemptive multitasking system.