4 ms·

Do not run untrusted code in the kernel. Period. Double period. Triple period. Speculative vulnerabilities and side channels are a lot more than just variant 1

• reitzensteinm 8y ago
  What if the sandbox completely denies any method of timing to the untrusted code? Including thread to thread communication. 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.
  • titzer 8y ago
    > What if the sandbox completely denies any method of timing to the untrusted code? Including thread to thread communication. 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.