Closed libbkmz closed 11 months ago
What wasm runtime does Envoy use? Knowing this would help me make progress in diagnosing this.
Could you try to reproduce this without Envoy, using just that wasm runtime, but without the Envoy-specific stuff?
Envoy uses wee8/envoy.wasm.runtime.v8
(https://www.envoyproxy.io/docs/envoy/latest/configuration/other_features/wasm) turned on by default (at least for Linux x86_64).
Testing the above code with latest envoy from envoyproxy/envoy-dev:79205cdde2dd07cd92f175b0d699b443b516fc5d
the errors are reduced:
[2022-07-22 11:47:22.235][2145515][error][wasm] [source/extensions/common/wasm/wasm_vm.cc:38] Failed to load Wasm module due to a missing import: __wbindgen_placeholder__.__wbindgen_describe
[2022-07-22 11:47:22.235][2145515][error][wasm] [source/extensions/common/wasm/wasm.cc:109] Wasm VM failed Failed to initialize Wasm code
The exact SHA used for wee8, https://github.com/envoyproxy/envoy/blob/79205cdde2dd07cd92f175b0d699b443b516fc5d/bazel/repository_locations.bzl#L889-L902
I'm also targeting wasm32-unknown-unknown
and trying to use a dependency that relies on ring
.
The error I'm seeing is: Module imports function 'LIMBS_are_zero' from 'env' that is not exported by the runtime.
Does anyone have any advice on a possible way forward? Thanks.
It seems like maybe https://github.com/briansmith/ring/pull/1176 is relevant and perhaps would have addressed the error I'm seeing.
There was a concern at the time around signing but I'm only interested in verifying when targeting wasm32-unknown-unknown
. https://github.com/briansmith/ring/pull/1440 is linked there but it sounds like there are still some issues with it when targeting Wasm.
Does anyone know anything more?
I'm trying out the tip of main
.
Now running into "could not find sysrand_chunk
in super
" as described in https://github.com/briansmith/ring/issues/1043
This appears to have worked: https://github.com/codebase-labs/ring/commit/11aafb0eb10287a9de5bcce6f190df0ecb18b718
I spoke too soon. Everything built but I'm back to the LIMBS_are_zero
issue.
Module imports function 'ring_core_0_17_0_not_released_yet_LIMBS_are_zero' from 'env' that is not exported by the runtime.
Actually I think it did work and I just ran into a stale lockfile issue.
Nope, I think the stale lockfile was giving me the impression that things were working when they weren't.
Trying this approach (env vars) next: https://github.com/briansmith/ring/issues/1483#issuecomment-1145159978
I've had no need for wasm-pack
as of yet but maybe I need to use that or figure out what it's doing under the hood.
I think the issue may be with extern "C"
being interpreted as "expect this from the environment" for Wasm modules but I'm not sure.
I tried to summarize things here: https://users.rust-lang.org/t/extern-c-and-wasm/83579
The main branch of ring (pending 0.17 release) does not use wasm-bindgen at all, as we've switched to using getrandom
, so the wasm-bindgen symbols shouldn't be required any longer on this branch.
The main branch of ring (pending 0.17 release) does not use wasm-bindgen at all, as we've switched to using
getrandom
, so the wasm-bindgen symbols shouldn't be required any longer on this branch.
I just tested this, and actually, getrandom
does not compile on wasm32-unknown-unknown
, unless you activate the js
feature, which brings back wasm-bindgen
. As I'm exploring I see that you already knew it, so I'm just leaving this here for others to see
I am not sure I'm going to be able to use the other working wasm targets; probably by registering my custom randomness source (that will always fail for my case)
People will need to make their own assessment on the security implications of this but I figured I should at least share what I did in https://github.com/betrusted-io/ring-xous/pull/2 to get a fork of ring
working for wasm32-unknown-unknown
.
I believe that ring 0.17 implements everything needed for this, except for a random number generator.
@gagbo wrote:
I just tested this, and actually, getrandom does not compile on wasm32-unknown-unknown, unless you activate the js feature, which brings back wasm-bindgen. As I'm exploring I see that you already knew it
The main question is, how are WeebAssembly plugins for Envoy supposed to get random bytes?
When researching the answer to that question, I found https://github.com/proxy-wasm/proxy-wasm-rust-sdk/issues/97 which indicates that you should use thw wasm32-wasi target instead of wasm32-unknown-unknown. That specifically will solve the random bytes issue and things will "just work." There is a PR #1568 that adds wasm32-wasi testing to ring's CI.
I'm going to close this as "not planned" because I assume everybody wlll switch to the wasm32-wasi target. LMK if that's not possible for some reason.
The main question is, how are WeebAssembly plugins for Envoy supposed to get random bytes?
I'm not using "Envoy", so I wouldn't know, but our in-house (@Fiberplane) plugin system gets its random bytes from the host runtime. We ship a wasmer runtime with custom bindings that allow access to a source of random bytes. And we didn't migrate to something that could target wasi as far as I know, so this wouldn't help.
On the other hand, our issue with ring
was a transitive issue from trying to use the AWS SDK crate to do a plugin around those services, and I bit the bullet and just removed my SDK dependency and rewritten every API call using manual API types and request signing. So this is not an issue for me anymore.
EDIT: and sorry for the delay in the response
PR #1754 will allow you to use the getrandom
crate's custom
feature to support wasm32-unknown-unknown.
However, in general I recommend people use a target that's not wasm32-unknown-unknown whenever practical so that such workarounds aren't necessary. (We should create wasm32-browser
and similar so that people don't need to use -unknown-unknown any more.)
Hello, I'm trying to use the ring's SHA and HMAC for
wasm32-unknown-unknown
target. I'm building the WASM plugin for the envoy proxy. The build procedure works, but I can't load the WASM file into envoy's. Here is the reproducible source: Cargo.toml:src/lib.rs:
Example configuration for envoy:
After building via
cargo build --target=wasm32-unknown-unknown
and running envoy viaenvoy --config-path envoy.yaml --concurrency 0 -l info
I'm getting this error from the envoy side:There are a lot of libraries that depend on the ring, however, I can't use them because of the broken dependency...