[_0w8t]

My point is that to run untrusted code it should be delivered in some form of bytecode, not the native code for CPU. This way one can always workaround CPU issues by changing the compiler or the interpreter even for catastrophic bugs in any part of CPU. Moreover, as hardware VM can execute much more instructions than unprivileged user processes, the probability that something unfixable will happen to them is higher then for ordinary processes.

As for statistics, there are strong indications that modern efforts for CPU verification do not keep up with increasing CPU complexity. So number and severity of bugs will grow.

[JdeBP]

I suggest reading this discussion about reinventing the AS/400: https://news.ycombinator.com/item?id=16053518

[walterbell]

Which bytecode do you recommend? Are you assuming the bytcode interpreter to be bug-free? There have been JVM escapes.

[_0w8t]

I do not assume that bytecode interpreter or compiler is bug free. But I assume that the interpreter can be trivially updated, while a bad CPU bug may require hardware replacement or taking terrible performance hit.

As for a particular bytecode format, I have no idea. Webassembly is a possibility, but it is still slower by factor of 2 compared with native code. Perhaps CPU-specific symbolic assembler will be a better choice as long as one can realibly alter it to workaround CPU bugs.