Specifying lockdown behavior
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 35/100
- Issue type
- Feature
- Clarity
- Needs clarification
- Activity status
- Active
- Tech stack
- javascript, wasm
Research direction
Start with the component invariants section of design/mvp/Explainer.md and CanonicalABI.md, then review JS-API issue #686 and the removal in #705. Determine where lockdown semantics and failures during ToComponentValue and lowering should be specified; done means the location and behavior are agreed and the relevant specification is updated.
Written by the indexing model from the issue text.
Description
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.
- Dominant language
- WebAssembly
- Stars
- 1.4k
- Forks
- 130
- Avg merge
- 2d 23h
- Merged PRs (30d)
- 14
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from WebAssembly/component-model
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
WebAssembly/component-model#609 · 2 comments · 1 reaction ·
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
WebAssembly/component-model#724 · 10 comments ·
-
Difficulty 5/5 Over a week Newbie friendliness 25/100
WebAssembly/component-model#695 · 1 comment ·
-
Difficulty 5/5 Over a week Newbie friendliness 45/100
WebAssembly/component-model#694 · 1 comment ·
-
Difficulty 5/5 Over a week Newbie friendliness 38/100
WebAssembly/component-model#677 · 1 comment ·
All issues in WebAssembly/component-model
Similar issues
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
-
area/profiles comp/cli comp/dashboard P2 sweeper:risk-session-state type/bug
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
NousResearch/hermes-agent#122365 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
vllm-project/production-stack#1105 ·
-
bug priority:low
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
CyberAgent/psd2svg#430 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100