Skip to content

feat: WASI support#69

Draft
nasdf wants to merge 1 commit intomainfrom
nasdf/feat/wasi-config
Draft

feat: WASI support#69
nasdf wants to merge 1 commit intomainfrom
nasdf/feat/wasi-config

Conversation

@nasdf
Copy link
Member

@nasdf nasdf commented Nov 15, 2023

Relevant issue(s)

Resolves #68

Description

This PR enables WASI imports with a new optional configuration flag.

Update: Drafting this for now until I've completed my tinygo wasi experimentation.

Tasks

  • I made sure the code is well commented, particularly hard-to-understand areas.
  • I made sure the repository-held documentation is changed accordingly.
  • I made sure the pull request title adheres to the conventional commit style (the subset used in the project can be found in tools/configs/validate-conventional-style.sh.
  • I made sure to discuss its limitations such as threats to validity, vulnerability to mistake and misuse, robustness to invalidation of assumptions, resource requirements, ...

How has this been tested?

Manually tested lenses with wasm32-wasi target.

If this feature becomes useful I think we should expand the test suite to run with both unknown and wasi compile targets.

Specify the platform(s) on which this was tested:

  • MacOS

@nasdf nasdf added the enhancement New feature or request label Nov 15, 2023
@nasdf nasdf self-assigned this Nov 15, 2023
@nasdf nasdf requested review from AndrewSisley and fredcarle and removed request for AndrewSisley November 15, 2023 17:11
@AndrewSisley
Copy link
Collaborator

todo: Please add tests for this within this PR :)

//
// This is a fairly expensive operation.
NewModule([]byte) (Module, error)
NewModule([]byte, bool) (Module, error)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

todo: I dislike that isWasi is a mandatory parameter, it complicates the simple-use case.

I think we should either auto-detect whether it is wasi or not, or make the param optional (...bool, or similar)

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we want to auto-detect we might want another top/runtime-level config-flag/param that disables wasi completely, as otherwise individual modules would be free to escape the wasm-sandbox with out much visibility.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree it should be optional, in fact it should use a more generic "functional options" like parameter so that we can add more Module options in the future, instead of it being explicitly a optional bool param.

Additionally, I also agree that we should be able to manually configure wasi support at the engine/runtime level, which if disabled, would throw an error if a module is instanciated with the WithWASI(true) (example syntax) included as an option.

func (rt *wRuntime) NewModule(wasmBytes []byte, wasi bool) (module.Module, error) {
ctx := context.TODO()
if wasi {
wasi_snapshot_preview1.MustInstantiate(ctx, rt.runtime)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

todo: This looks like it is enacted on the runtime, not the module - the other lens-runtimes looked safe enough, but this one very much looks like we should test the mixing on wasi and non-wasi modules within the same runtime (in this PR)

@nasdf nasdf marked this pull request as draft November 27, 2023 18:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

WASI support

3 participants