|
|
|
|
|
by azakai
1802 days ago
|
|
You're right that it doesn't remove all risk automatically. You can still corrupt data inside the sandbox. However, wasm has a very clear sandboxing boundary. The ability of an exploit to escape the sandbox is very small if you are careful there. IIUC the task here is a user that wants to parse their own files. For that, I think wasm's sandboxing (if used properly) is very useful. Especially since in this case it runs on the web and so we also have the browser's additional isolation (a sandboxed process). Memory safety is incredibly important, but there isn't a simple answer in the space of tradeoffs, at least not for tasks like this. (For things like running an executable on bare metal that parses arbitrary inputs, obviously things are very different!) |
|
So now think what might happen, when not used properly.
Some form of bounds checking should have been part of the design, like memory tagging.