CPU features like software controlled cache compartmentalization could also help, preventing cache related side channel leaks.
> The same comes when you allow random untrusted code be JITed or even ran as is with WASM.
If it's single threaded and WASM "syscall" interface doesn't provide anything that can be used as a clock, I don't see there's much to exploit — as long as each syscall interface itself is secure against direct and side channel attacks.
> ...remove JIT compilation of untrusted code.
You could probably still be able to exploit these issues, just somewhat slower. Also interpreters need to access memory, and those patterns are highly predictable.
As evidenced by the struggles of browser developers, making a solid sandbox is -hard-. They've been trying to make JS secure and sidechannel free for a good part of 15 years now, and there are still issues found every quarter.
It will not help you. Anything short of specially built CPU architecture and an OS is useless against hardware level "attacks," if you can even call them that.
CPUs are simply not built with an idea that you have to protect one process from another, and do it on that level of sophistication. You normally don't have that concern if the only person who can run code on a CPU is its user.
But the whole paradigm breaks when you have multiple "tenants" in a single systems, and whose entire setup is not managed by the host.
The same comes when you allow random untrusted code be JITed or even ran as is with WASM.
The only solution against that is to stop people from using "virtual" hosting, and remove JIT compilation of untrusted code.