Stream: git-wasmtime

Topic: wasmtime / issue #1061 A "safe" subset for Cranelift IR

Wasmtime GitHub notifications bot (Jan 26 2023 at 19:04):

bjorn3 commented on issue #1061:

Heap_addr is gone now. Is this still something we want to persue?

Wasmtime GitHub notifications bot (Jan 26 2023 at 19:05):

bjorn3 edited a comment on issue #1061:

Heap_addr is gone now. Is this still something we want to pursue?

Wasmtime GitHub notifications bot (Jan 26 2023 at 20:59):

cfallin commented on issue #1061:

We've moved in the opposite direction, making CLIF lower-level and lifting the heap-sandboxing abstractions into cranelift-wasm. I think I'll go ahead and close this as there does not really seem to be a concrete use-case on the table (and a robust sandbox built from CLIF would need significant thought on many other aspects too, which Wasm has already done). That doesn't mean we'd never consider this in the future but I don't think it's really necessary to keep an open issue for it, IMHO.

Wasmtime GitHub notifications bot (Jan 26 2023 at 20:59):

cfallin closed issue #1061:

What if we added heap_load and heap_store instructions, which would roughly be legalized into heap_addr+load and heap_addr+store. That way, frontends could produce Cranelift IR without themselves dealing with plain load and store, which would eliminate the possibility of misusing them and facing undefined behavior.

The next step would be to add a wasm-like indirect call instruction, possibly named table_call. This would be more complex because we don't yet have a builtin way to legalize this that includes signature checking, but it's doable.

Then, it's plausible to imagine defining an IR subset which is completely safe, yet still reasonably complete. We could then clearly document unsafe constructs like load and store as such, possibly with an optional verifier pass that could enforce that no unsafe constructs are present, and make it easy for people to generate IR without having to worry about undefined behavior.

Last updated: Nov 22 2024 at 16:03 UTC