Speculative vulnerabilities and side channels are a lot more than just variant 1 and 2.
WasmJIT is a nice project. But let me repeat. Do not put it in the kernel and run untrusted code through it, period. Software mitigations are not sufficient. This is not WASM's fault, this is not WasmJIT's fault; it's just a fundamental reality of modern hardware.
Timing related side channels seem unavoidable, but that doesn't mean that answer in -> answer out computation is necessarily intrinsically able to perform it.
Also, if you can trust code to not be malicious, but not to be correct, loading code via WASM and executing it in the same address space isn't necessarily crazy.
You can construct timers from shared mutable memory (think: counter thread), but even in shared-nothing systems, one can construct timers using message passing (think: a crude timer that counts messages in one process and a sender hammering it with messages).
> Also, if you can trust code to not be malicious, but not to be correct, loading code via WASM and executing it in the same address space isn't necessarily crazy.
Sure, agreed. This is why my comment mentioned untrusted code. WebAssembly sandboxing makes sense to protect the kernel from OOB writes, but it cannot guarantee no OOB reads from speculative side-channels.