Can reduce lucet-wasi dependencies by splitting the launcher and library

[shravanrn]

Context This is part of a series of bugs that I spoke to @tyler @pchickey about. We are currently using Lucet to sandbox libraries in C++ applications. The idea behind this is that using a wasm sandboxed version of the library allows ensuring that a memory safety issue in the library does not automatically result in a memory safety vulnerability in the full application. One of the consumers of this work is the Firefox web browser.

Problem lucet-wasi is including extra dependencies that will be unused for some use cases. This is because lucet-wasi seems to serve dual purposes.

1. To allow loading of wasm sandboxed libraries I need to include lucet-wasi as a library in the application as it provides the WasiCtx (environment variables, file descriptors, permission to use stdio etc.) for the wasm module.
2. lucet-wasi was also provides a second piece of functionality - a command line utility which acts an application launcher that can launch wasm applications

The second use case uses dependencies like human-size to parse options which are unused in the first use cases.

In order to simplify the dependency story here, would it make sense to split lucet-wasi into 2 separate packages according to the above (i.e. a library and a launcher utility)?

Actions Please let me know your thoughts on this. If this sounds good, please also let me know if this is a change that can happen internally or if it would be better if a work on a patch that can be accepted?

[acfoltzer]

We're already in the process of reworking lucet-wasi to use the shared wasi-common hostcall implementations, so I wouldn't recommend working on a patch until that lands, in order to avoid merge conflicts.

Along the way, we will make sure the CLI tool is a separate crate. In the meantime, you can use the wasi-common adapter that we will be merging into lucet-wasi.

I'm now keeping an eye on https://github.com/rust-lang/cargo/issues/1982 to know when this will no longer be an issue.

[shravanrn]

Thanks for the clarifications! I think if these items are already in the roadmap, it makes sense for me to hold off until the changes land.

@acfoltzer - while we are on the subject of lucet-wasi modifications, I was wondering about something else. It would be awesome to have a way in lucet-wasi that disables networking related functionality, in case consumers want to explicitly disallow that... Given the upcoming changes, would you know which of the above would be right repo to file a bug for this discussion - lucet-wasi, wasi-common, or something else?

[acfoltzer]

On the API design side, I believe the plan is still to have WASI be divided into distinct modules, eg wasi-fs, wasi-rand. I expect there will be a module specifically for networking that can be reasoned about separately.

In terms of implementation, the current way to disable functionality is to exclude it from the bindings.json file. However, as we've discussed in #277 this may change to a more dynamic approach, in which case the CLI frontend of lucet-wasi is probably the right place to add configuration knobs for the different WASI modules.