3 ms·
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 issu
by fpoling 9y ago
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.
- walterbell 9y agoWhich bytecode do you recommend? Are you assuming the bytcode interpreter to be bug-free? There have been JVM escapes.
- fpoling 9y agoI 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.
- JdeBP 9y agoI suggest reading this discussion about reinventing the AS/400: https://news.ycombinator.com/item?id=16053518 https://news.ycombinator.com/item?id=16053518