Should WASI attempt to specify any form of resource limits?

[alexcrichton]

This issue is borne out of a recent CVE in Wasmtime in addition to two related issues -- #888 and #889. The basic summary is: should WASI document any sort of guarantees for guests with respect to resource consumption?

Previously Wasmtime had a few issues with it orthogonal to any particular WASI API:

• Wasmtime had no limit on the number of Component Model resources that could be created. For example you could infinitely call wasi:clocks/monotonic-clock.subscribe-duration. This would store no resources on the guest side of things but it would force the host to grow the resource table quiet large.
• Wasmtime had no limit on the size of values being copied from the guest to the host. For example by calling wasi:filesystem/types.descriptor#write a guest could force an allocation of arbitrary size to get copied to the host. An extreme case of this is wasi:http/types.fields#from-list where by passing a nested list to the host it's possible for the guest to create a quadratically-sized allocation on the host.

For both of these issues Wasmtime now has hardcoded limits after which a guest will trap, but like with #888 and #889 this is considered a bit of a band-aid than a true fix. The question here is: should WASI specify anything in this regard? Should WASI place a hard limit on the size of buffers transmitted to the host? Should WASI provide some sort of function indicating the maximum number of resources the guest can allocate? (e.g. POSIX ulimit)

WASI could, for example, provide ulimit-style functions to get/set limits. This would serve the purpose of informing the guest as to what the limits currently are and additionally provide the ability to raise the limits if the host allows it. Hosts could then provide much smaller by-default limits which have different hard caps that cannot be increased.

Alternatively WASI could document, individually for all functions with anything list-like, what the maximum size of the list is that's allowed. Hosts would be forced to support up to that amount but guests could expect traps when exceeding this amount.

---

Overall I'm not sure what the best direction forward is myself, and I'm curious what others think! I feel though this is distinct enough from #888 and #889 to warrant its own issue, but it may also end up with the same resolution for all these issues.

[fitzgen]

I think at creating new resources should be allowed to non-deterministically fail, similar to memory.grow, table.grow, struct.new, etc... in core Wasm.

I am ambivalent/soft-negative on providing some API for Wasm guests to reflect on the current limit, if any. If the engine/embedder did not configure a limit and did not pre-allocate the resource table, then the limit is effectively "until we OOM" and the point at which that OOM gets hit is still going to be non-deterministic. So guests couldn't trust this API even if it existed.

---

But, as you know, the size of the resource table aren't the only thing that needs limits. Any component call to the host can require a copy out of linear memory into a new host allocation in certain situations, so we need the spec to allow any component call to non-deterministically trap if the data passed across the call is too large. That seems like an easy thing to do at the component-model layer, rather than WASI, and should actually also (from a spec POV) supersedes tweaking the WASI spec to allow any specific call or resource creation to non-deterministically fail.