Hacker News Reader

Comment by plutonorm | Hacker News Reader

I wager it will be hacked in under a year.

What exactly do you mean by hacked? This isn't a product with some singular security aim, it's an evaluation platform that's come from an ongoing large research project. Previous work (using FPGA and software simulation) will have found and fixed many architectural issues. No doubt more will be found here.

In a sense the entire aim of this is for it to be 'hacked' to further improve the security architecture.

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.

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.

There are no CVEs related to Solaris SPARC Application Data Integrity, or Unisys ClearPath MCP.

Either they aren't interesting for hackers, or they actually did a good job with hardware memory tagging.

I might imagine the former over latter

Might be, then again most of their customers are government agencies, not really something that hackers care about.

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.

Thank you. Your response's here and throughout this thread have been quite enlightening.

Exactly - these formal methods have implicit assumptions in them. Within their axioms/priors they are proven correct. But the devil is in those assumptions. And that is disregarding the rather foggy notion of 'proof'. Is this proof written in a formal proof system that automates the proof? Because if it isn't you have another source of error. Even if it is in a formal proof system, who is to say that there is no error in the formal proof system? I admit that each layer adds more assurance - but appealing to 'formal proof' is a bit like appealing to god, it's an appeal to an unassailable authority. When in fact, once you know the details these things are never so clear cut.

Do you have criticisms of the feature or is this facile cynicism?

Reply on news.ycombinator.com