Stream: general

Topic: ✔ using wit-bindgen in mobile rust

fero (Oct 10 2022 at 21:21):

Hello, the readme said to reach out, so we're doing that. Briefly, we're looking to use Rust written WASM, interpreted in Rust runtime via something like wasm3 or wasmtime. That's why we're looking to potentially depend on wit-bindgen. First of all, does this make sense? Secondly, what would be the community's suggestion on the interface? (if any) we're thinking of passing a vec<u8> to/from WASM like so:

fn handle(a: vec<u8>) -> vec<u8> {
  // 1. parse, 2. do work, 3. return bin repre
}

Some loose requirements/expectations:

1. both ends should know the alignment to parse the input/output of the handle function
2. we will use the vec<u8> parser/printer in mobile context, with other languages (Kotlin/Swift), not just Rust
3. we'd like to share Rust entities and use them in both host (rust) and guest (rust) runtime
4. the Rust runtime itself will be relatively hollow, most of the logic should reside in Rust-written-WASM

given the above, what resources/tech do you recommend? is wit-bindgen a good fit? it looks like the solution to us b/c interface types are not maintained now, and quite heavy (i.e. wasm-bindgen assumes a lot of JS type inter-op that we don't need). we want something fast, with small binary size, and ideally future proof (not another abandoned experiment).

if something is too vague pls lmk and i can clarify

Lann Martin (Oct 10 2022 at 21:30):

I am not an iOS developer, but my vague understanding is that app store rules will not allow a code execution engine like wasmtime to be embedded in an app

Ramon Klass (Oct 10 2022 at 21:35):

I also distinctly remember a game that was removed because it had an embedded python interpreter

fero (Oct 10 2022 at 21:37):

yes, that's why we're looking to use wasm3, avoiding JIT, using an interpreter instead (allowed)

Lann Martin (Oct 10 2022 at 21:47):

If you are targeting wasm3 you probably do not want to use wit-bindgen at this time

Lann Martin (Oct 10 2022 at 21:52):

It could be made to work with significant effort, but if your interface is just "bytes in, bytes out" you would likely find it easier to manipulate the wasm linear memory directly from the host

fero (Oct 10 2022 at 21:58):

in that case, are you maybe aware of a more lightweight way of generating the bindings than w/ wasm-bindgen? we want to avoid relying on any of the JS associated baggage (https://github.com/rustwasm/wasm-bindgen/issues/5)

Lann Martin (Oct 10 2022 at 22:07):

I am not aware of any other simple solution, but I haven't personally looked recently. What wit-bindgen does internally - roughly - is allocate memory on the guest side and pass a pointer to that allocation to the host, which then copies the data into linear memory at that pointer

fero (Oct 11 2022 at 13:25):

okay, then we'll try to mimic what wit-bindgen does internally, and go from there. thanks for the rubber-ducking Lann :pray: :)

Notification Bot (Oct 11 2022 at 13:26):

fero has marked this topic as resolved.

mako yass (Oct 31 2022 at 06:30):

Lann Martin said:

I am not an iOS developer, but my vague understanding is that app store rules will not allow a code execution engine like wasmtime to be embedded in an app

This seems to have changed recently? https://developer.apple.com/documentation/bundleresources/entitlements/com_apple_security_cs_allow-jit

bjorn3 (Oct 31 2022 at 10:13):

That is a macOS only entitlement.

bjorn3 (Oct 31 2022 at 10:14):

There is an iOS equivalent, but it only works for local development. You can't use it in appstore apps.

Lann Martin (Oct 31 2022 at 14:17):

And for most purposes you really have to look at app store policy rather than developer documentation to get the whole story

mako yass (Oct 31 2022 at 18:34):

Does it being allowed with local development indicate that it's going to be allowed for appstore apps at some point? (if so I wonder what might be driving the change)

bjorn3 (Nov 01 2022 at 00:25):

I don't think so. If anything I wouldn't be surprised to see it disappear entirely in the future. Basically the only system app with this entitlement is Safari (even non-apple browsers can't use it) and when using Lockdown mode Safari doesn't use it either, but falls back to a javascript interpreter.

akesling (Nov 01 2022 at 18:47):

For some clarification/context: including language runtimes is 100% allowed on iOS. See React Native (JS/V8) and Flutter (Dart) as examples of this. wasm isn't special in this regard.

The relevant iOS app store guidelines are about dynamically shipping new logic to your app _after_ it has been reviewed (i.e. when a user is running the app, new logic being presented to them that was not present in the app during review).

You should be fine as long as you both
A) don't violate local iOS security policy / guidelines (e.g. JIT compilation to ARM/native and dynamic jumps into that code segment are effectively disallowed by default, though this restriction may be loosening as per the previous reply on this thread), and
B) statically include all logic that will run when a user is using the app (excluding that run in a WebView, which can ostensibly be loaded dynamically as in a web page... which has its own subtleties to consider) .

This means that (AFAIK) Wasmtime _at the moment_ may not be the best option as it doesn't have a straightforward interpreter mode (though maybe this will change?). Straight up interpreting via something like wasm3, or compiling to statically link via something like RLBox should be fine (again, as long as the wasm source was shipped _statically_ in the app archive to install).

P.S. I'm working on a general-purpose "universal plugin" solution for mobile apps using wasm if anyone wants to talk more about the subtleties of running on iOS, Android, and beyond. I'm _very_ interested in people's usecases and where existing tooling can be improved ;).

Steve Manuel (Nov 01 2022 at 18:53):

@akesling I’m very interested in your mobile plugin solution! we’re working on a similar problem in other platforms with Extism, but mobile is definitely on the roadmap. Maybe we can collaborate?

Pat Hickey (Nov 03 2022 at 20:55):

if its only jitting code that is against the rules, and mmaping + marking as executable code that is bundled with your app is allowed, then you can still use wasmtime in AOT mode: if you disable the cranelift feature, then you can use Module::deserialize to load code that was emitted by Module::serialize elsewhere

Last updated: Nov 22 2024 at 16:03 UTC