Specifying lockdown behavior

[eqrion]

Component invariants state:

Components define a "lockdown" state that prevents continued execution after a trap. This both prevents continued execution with corrupt state and also allows more-aggressive compiler optimizations (e.g., store reordering). This was considered early in Core WebAssembly standardization but rejected due to the lack of clear trapping boundary. With components, each component instance is given a mutable "lockdown" state that is set upon trap and implicitly checked at every execution step by component functions. Thus, after a trap, it's no longer possible to observe the internal state of a component instance.

I don't see anything in CanonicalABI.md about this, does this still need to be specified? There was a may_enter flag that was removed in #705.

I'm asking because the JS-API (#686) needs to care about lockdown semantics, and I wasn't sure if it should define it in the JS-API or in CanonicalABI.md.

For the JS-API, it'd be great to fuse the destructuring of JS values (ToComponentValue) with the lowering of the component value into linear memory. However, destructuring a JS value can fail (type mismatches) and also lowering the component value can fail (OOBs). So ideally we could have both kinds of failures lead to a lockdown of the component such that it's not observable what happened to the internal wasm state.

If this is just missing, I can add it to CanonicalABI.md, I think that's the right place for it.

[lukewagner]

Yes, this has just been missing from CanonicalABI.md since the very beginning, but I can add it real quick. I suppose if it's specified as an immediate trap on the entry path (rather than assertion ensured by the host) then the JS-API wouldn't need to do anything special beyond handling traps as usual.

[eqrion]

Okay, thanks. The JS-API can handle traps, the one additional thing it'd like to do is trigger lockdown if an argument conversion fails.

func log(a: resource, b: resource)

If I do log("good", undefined /*bad*/), the JS-API wants to throw a TypeError (not trap), but then it's also ideal to not be able to see if the "good" was written into linear memory or not. So having an embedder API for setting the lockdown bit would be great.

[lukewagner]

Ah, interesting point; that makes sense. I'll include an a way for embedders to set the bit.