zlacker

>>zxombi+(OP)
I wager it will be hacked in under a year.

>>pluton+Y7
Nobody's claiming it's "hack-proof", that would be foolish, just that it removes certain classes of vulnerabilities that are the majority of CVEs for code written in memory-unsafe languages, thereby reducing the attack surface. Independent analysis by both Microsoft and Google has shown that's around 70% of vulnerabilities, which still leaves around 30%, but is a big step forward.

>>jrtc27+Qc
Not OP, but that's not how I interpreted their comment. I interepreted it as the 70% they hope to have fixed will end up having edge cases not yet considered, and the protections will end up weaker than desired. No-one designed a processor to be susceptable to spectre and meltdown, once something moves into production there is significantly more incentive to investigate and find these flaws.

>>lacksc+hf
We do have formal proofs of various security properties at the architectural level that consider the entire architecture with all its complexities and warts. Speculative execution is of course a concern (and is an active area of research for us), though our belief is that the bounds information now present at the hardware level allows it to be tamed. Another concern is the interaction between undefined behaviour and CHERI; the former needs to be sufficiently constrained in order to not inadvertently turn code that would be memory safe with a naive CHERI compiler into code that is not. We also know there are still memory safety-like issues we can't protect against; we can stop pointer injection, but we can't stop tricking programs into copying the "wrong" pointer somewhere, or type confusion bugs that result in using pointers in an unintended way. Many of those exploit chains today rely on exploiting some other memory safety vulnerability we do protect against, but we cannot predict if people will come up with alternative approaches that avoid those in a world with CHERI.