I failed to design a CPU yesterday specifically suited to voice recognition, but today I'd like to explain how I'd (naively) design a general purpose CPU to address their current vulnerabilities.
Basically I'd add length & permissions data to every pointer (making them 128bits long), and store a bitmask indicating which bytes are pointers. Thereby moving more fine-grained security checks into the hardware.
This would break *some* C programs, but the damage should be minimal and worth it.
These checks (especially if the length is negated) can be performed on a bog-standard vectorized ALU, though propagating permissions and checking the bitmask would require a bit of additional circuitry. Mostly it's the machine code input which would change.
Though this CPU could then take advantage of these security constraints to replace today's complex prefetchers & branch predictors with a simple breadth-first graph traversal!
@alcinnz I know nothing about hardware design, and I don't understand the specifics of what you have described, but I like the notion. I think speculative execution and caching primitives (and maybe more complexities of CPU I don't know of) should have been exposed in the instruction set for software to use, opt in. I speculate that it was wholly implemented in hardware/firmware because the vendors were catering to proprietary software, that they could not guarantee(or require) to be recompiled for the new hardware design.