zlacker

They're actually pretty simple if you're mostly trying to defeat software/firmware attacks. You just add some part to run in parallel with the processor, which can be arbitrarily simple or complex, that checks certain things about the data such as length or data type. The first one was implemented in 1961 hardware with it being secure from code injection until the invention of ROP. That's a long time. I'll add a modern take on that which led to a flexible mechanism that can do a dozen or maybe more policies.

http://www.smecc.org/The%20Architecture%20%20of%20the%20Burr...

http://www.crash-safe.org/papers.html

A more complex one is below that was also designed by one person for his dissertation. Knocks out all kinds of issues without modifying the processor. It has stuff to improve for sure but it think it proves the point pretty well. The stuff corporate teams were designing comes nowhere near this because they don't know much about high-security design. A critical part of that isn't features so much as a balancing act between what protection mechanisms do and don't that tries to minimize complexity to low as is possible.

https://theses.lib.vt.edu/theses/available/etd-10112006-2048...

And one open-source one on MIPS for capability-based security that runs FreeBSD:

https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/

A company or group of hardware volunteers could develop this into something at least as usable as a multi-core ARM CPU on RISC-V or OpenSPARC. It wouldn't take tons of money esp if they worked their way up in complexity. The hard stuff is already done. People just need to apply it. They could even pay these academics to do it for them with open-sourced results. They even get a huge discount on the EDA tools that can be six digits a seat.

You're right that Intel is screwing up and playing catchup cobbling together features. There was stuff in the available literature better than most of what they're doing. They even have a separation kernel from Wind River they're not employing. Managers without security expertise must be pushing a lot of this stuff.

>>nickps+(OP)
The theory is simple. I'm somewhat inclined to think it is not so easily applicable.

It is easy to make a secure coprocessor, since the formal logic proofs aren't for such a long set of code.

The fact that rootkits are even possible, that without malware that doesn't involve an elaborate rewrite of the kernel, shows how terrible everything is.

If I didn't know any better, I'd say that Intel is hiring the designers who thought Internet Explorer should be in the kernel.

>>nickps+(OP)
Ain’t no problem that couldn’t be solved by adding another layer of indirection, eh?

>>gggvvh+R7
Maybe in web or application software. In hardware, it all runs in parallel. The mechanism of something like SAFE becomes another component receiving input in the CPU pipeline. A conditional of sorts is added so the final write back to whatever memory doesn't happen unless the safety/security checks passed. The failure mode might also do an interrupt for OS so it could log the where and why of the failure. As in, application flaws could be patched quickly.