The current wasmedgec compiler generates optimized binary code for the specific CPU it runs on. But in some cases, we need the compiled SO file to run on a slightly different CPU.

We would like to have a CLI flag on wasmedgec to generate the lowest common denominator binary code for generic x86 and aarch64 CPUs.

We should have a shared library for SSVM C API.

1. SSVM Runner
2. SSVM AOT Compiler
3. cpack for releasing

The automatically fetching repositories if not found when calling find_package() in cmake will have the following warning:

CMake Warning at lib/common/CMakeLists.txt:3 (find_package):
  By not providing "Findspdlog.cmake" in CMAKE_MODULE_PATH this project has
  asked CMake to find a package configuration file provided by "spdlog", but
  CMake did not find one.

  Could not find a package configuration file provided by "spdlog" with any
  of the following names:

    spdlogConfig.cmake
    spdlog-config.cmake

  Add the installation prefix of "spdlog" to CMAKE_PREFIX_PATH or set
  "spdlog_DIR" to a directory containing one of the above files.  If "spdlog"
  provides a separate development package or SDK, be sure it has been
  installed.

And so does the gtest.

For the gtest, there are also the following warnings:

CMake Warning (dev) at build/_deps/gtest-src/googletest/cmake/internal_utils.cmake:150 (add_library):
  Policy CMP0069 is not set: INTERPROCEDURAL_OPTIMIZATION is enforced when
  enabled.  Run "cmake --help-policy CMP0069" for policy details.  Use the
  cmake_policy command to set the policy and suppress this warning.

  INTERPROCEDURAL_OPTIMIZATION property will be ignored for target
  'gmock_main'.
Call Stack (most recent call first):
  build/_deps/gtest-src/googletest/cmake/internal_utils.cmake:202 (cxx_library_with_type)
  build/_deps/gtest-src/googlemock/CMakeLists.txt:103 (cxx_library)
This warning is for project developers.  Use -Wno-dev to suppress it.

As #318 occurred because CI missed the case, it might be good to test all options (or combinations) at least before each release.

https://bestpractices.coreinfrastructure.org/en

This is a requirement for CNCF graduation down the line and honestly helps you implement best practices.

To whom it may concern,

I'm Syrus Akbary, CEO and Founder of Wasmer, Inc. We recently learned that your company, has started using the name WasmEdge.

We are the owners of wasmedge.com since December 2020 and we had already started the process of filing the trademarks for it.
I urge you to change the name of the project so it doesn't collide with ours.

Best,
Syrus

The libwasmedge_c.so in the .deb file failed.

Motivation

The wasm-c-api proposal provides the C and C++ API for WASM runtimes. Even though WasmEdge already provided the C API, it's proper to implement the wasm-c-API proposal for the general C/C++ API.
In the current status, we've already implemented the non-runtime data structures on the branch. Then, we need to finish the runtime implementation.

Specification

1. Follow the Spec of WASM-C-API proposal and work on the branch.
2. Implement the WASM C/C++ API by calling the WasmEdge classes or WasmEdge C API.
3. Add the customized wasm_config_t functions for the runtime configurations.
4. Complete the Wasm C/C++ API unit tests for the coverage.
5. Pass the WASM core tests without the SIMD proposal.

Appendix

1. WASM C API proposal: https://github.com/WebAssembly/wasm-c-api
2. WASM spec core tests: https://github.com/WebAssembly/spec/tree/master/test/core

Please add maynlinux1 builds for aarch64 and armv7 (32 bit interpreter only) into the release artifacts. Thank you.

Making WasmEdge be a JS runtime, which may be friendly to the frontend developers.

Please fork this repo and complete the challenge in your own repo. Once you are done, post your repo’s github link, as well as a screenshot demonstrating the logging messages, as a comment under this issue.

OpenTelemetry is a new standard for cloud native application logging, tracing, and monitoring. It has agent SDKs in mainstream programming languages, including C++.

https://opentelemetry.io/docs/

This coding challenge is to embed a C++ agent into WasmEdge. The agent logs messages from WasmEdge to STDOUT. You could use OpenTelemetry agent to replace existing logging calls in the code. You do NOT to replace logging for the entire project. Just do it in a few places, either to replace existing logging or add new logging, to demonstrate that you know how to do it.

Examples:

https://github.com/open-telemetry/opentelemetry-cpp/tree/main/examples/simple

https://github.com/open-telemetry/opentelemetry-cpp/tree/main/examples/metrics_simple

Good luck!

Related to #290

Add a WASI option to list external commands this SSVM instance is allowed to call. Unlisted commands should fail with a security exception.

Add a memory object

void FormChecker::addMemory(const AST::MemoryType &) {
  Mems.push_back(Mems.size());
}

Checking number memory objects

if (Mems.size() <= N) {
  // error handling
} 

All these operations can be done by a single unsigned integer representing the size

OS :Widows 10

λ npm i ssvm

> [email protected] install C:\Users\Administrator\Desktop\fmt\node\node_modules\ssvm
> node-pre-gyp install --fallback-to-build

node-pre-gyp WARN Using needle for node-pre-gyp https download
node-pre-gyp WARN Tried to download(404): https://github.com/second-state/ssvm-napi/releases/download/0.4.12/ssvm-win32-x64.tar.gz
node-pre-gyp WARN Pre-built binaries not found for [email protected] and [email protected] (node-v72 ABI, unknown) (falling back to source compile with node-gyp)
在此解决方案中一次生成一个项目。若要启用并行生成，请添加“/m”开关。
  addon.cc
  ssvmaddon.cc
  description.cpp
  expression.cpp
  class template variant is only available with C++17 or later.
c:\users\administrator\desktop\fmt\node\node_modules\ssvm\ssvm-core\include\common\ast.h(52): error C7525: 内联变量至少需要 "/std:c++17" (编译源文
件 ..\addon.cc) [C:\User
s\Administrator\Desktop\fmt\node\node_modules\ssvm\build\ssvm.vcxproj]
c:\users\administrator\desktop\fmt\node\node_modules\ssvm\ssvm-core\include\common\ast.h(52): error C7525: 内联变量至少需要 "/std:c++17" (编译源文
件 ..\ssvm-core\lib\ast\
expression.cpp) [C:\Users\Administrator\Desktop\fmt\node\node_modules\ssvm\build\ssvm.vcxproj]
c:\users\administrator\desktop\fmt\node\node_modules\ssvm\ssvm-core\include\common\types.h(30): error C7525: 内联变量至少需要 "/std:c++17" (编译源
文件 ..\ssvm-core\lib\as
t\description.cpp) [C:\Users\Administrator\Desktop\fmt\node\node_modules\ssvm\build\ssvm.vcxproj]
c:\users\administrator\desktop\fmt\node\node_modules\ssvm\ssvm-core\include\common\ast.h(52): error C7525: 内联变量至少需要 "/std:c++17" (编译源文
件 ..\ssvmaddon.cc) [C:\
Users\Administrator\Desktop\fmt\node\node_modules\ssvm\build\ssvm.vcxproj]
c:\users\administrator\desktop\fmt\node\node_modules\ssvm\ssvm-core\include\common\types.h(38): error C2039: “variant”: 不是“std”的成员 (编译
源文件 ..\ssvm-core\lib\as
t\description.cpp) [C:\Users\Administrator\Desktop\fmt\node\node_modules\ssvm\build\ssvm.vcxproj]
c:\users\administrator\desktop\fmt\node\node_modules\ssvm\ssvm-core\include\common\ast.h(281): error C7525: 内联变量至少需要 "/std:c++17" (编译源
文件 ..\ssvm-core\lib\ast
\expression.cpp)c:\program files (x86)\microsoft visual studio\2017\community\vc\tools\msvc\14.16.27023\include\unordered_map(20): note: 参见“std
”的声明 (编译源文件 ..
\ssvm-core\lib\ast\description.cpp) [C:\Users\Administrator\Desktop\fmt\node\node_modules\ssvm\build\ssvm.vcxproj]

c:\users\administrator\desktop\fmt\node\node_modules\ssvm\ssvm-core\include\common\ast.h(281): error C7525: 内联变量至少需要 "/std:c++17" (编译源
文件 ..\addon.cc) [C:\Use
rs\Administrator\Desktop\fmt\node\node_modules\ssvm\build\ssvm.vcxproj]
c:\users\administrator\desktop\fmt\node\node_modules\ssvm\ssvm-core\include\common\types.h(38): error C2061: 语法错误: 标识符“variant” (编译源文
件 ..\ssvm-core\lib\ast\d
escription.cpp) [C:\Users\Administrator\Desktop\fmt\node\node_modules\ssvm\build\ssvm.vcxproj]
c:\users\administrator\desktop\fmt\node\node_modules\ssvm\ssvm-core\include\common\ast.h(281): error C7525: 内联变量至少需要 "/std:c++17" (编译源
文件 ..\ssvmaddon.cc) [C:
\Users\Administrator\Desktop\fmt\node\node_modules\ssvm\build\ssvm.vcxproj]
c:\users\administrator\desktop\fmt\node\node_modules\ssvm\ssvm-core\include\common\types.h(46): error C7525: 内联变量至少需要 "/std:c++17" (编译源
文件 ..\ssvm-core\lib\as
t\description.cpp) [C:\Users\Administrator\Desktop\fmt\node\node_modules\ssvm\build\ssvm.vcxproj]
c:\users\administrator\desktop\fmt\node\node_modules\ssvm\ssvm-core\include\common\types.h(57): error C7525: 内联变量至少需要 "/std:c++17" (编译源
文件 ..\ssvm-core\lib\as
t\description.cpp) [C:\Users\Administrator\Desktop\fmt\node\node_modules\ssvm\build\ssvm.vcxproj]
c:\users\administrator\desktop\fmt\node\node_modules\ssvm\ssvm-core\include\common\ast.h(52): error C7525: 内联变量至少需要 "/std:c++17" (编译源文
件 ..\ssvm-core\lib\ast\
description.cpp) [C:\Users\Administrator\Desktop\fmt\node\node_modules\ssvm\build\ssvm.vcxproj]
  class template variant is only available with C++17 or later.
  class template variant is only available with C++17 or later.
  class template variant is only available with C++17 or later.
c:\users\administrator\desktop\fmt\node\node_modules\ssvm\ssvm-core\include\common\ast.h(281): error C7525: 内联变量至少需要 "/std:c++17" (编译源
文件 ..\ssvm-core\lib\ast
\description.cpp) [C:\Users\Administrator\Desktop\fmt\node\node_modules\ssvm\build\ssvm.vcxproj]
c:\users\administrator\desktop\fmt\node\node_modules\ssvm\ssvm-core\include\common\types.h(30): error C7525: 内联变量至少需要 "/std:c++17" (编译源
文件 ..\addon.cc) [C:\Us
ers\Administrator\Desktop\fmt\node\node_modules\ssvm\build\ssvm.vcxproj]
c:\users\administrator\desktop\fmt\node\node_modules\ssvm\ssvm-core\include\common\types.h(30): error C7525: 内联变量至少需要 "/std:c++17" (编译源
文件 ..\ssvm-core\lib\as
t\expression.cpp) [C:\Users\Administrator\Desktop\fmt\node\node_modules\ssvm\build\ssvm.vcxproj]
c:\users\administrator\desktop\fmt\node\node_modules\ssvm\ssvm-core\include\common\types.h(38): error C2039: “variant”: 不是“std”的成员 (编译
源文件 ..\addon.cc) [C:\Us
ers\Administrator\Desktop\fmt\node\node_modules\ssvm\build\ssvm.vcxproj]
  c:\program files (x86)\microsoft visual studio\2017\community\vc\tools\msvc\14.16.27023\include\unordered_map(20): note: 参见“std”的声明 (编译
源文件 ..\addon.cc)

things too much ,can't show
https://github.com/second-state/ssvm-napi/releases/download/0.4.12/ssvm-win32-x64.tar.gz
this thing I can download in the web page but maybe can't download in Terminal .
Do I need manual install ssvm

Hi, I just pass Uint8Array, but got TypeError: vm.Run is not a function

I'm writing small programs in text format to test WASI support of various runtimes (eg. Wasmtime, Wasmer, etc.). I have this program to test fd_close:

(module
  (type (;0;) (func))
  (type (;1;) (func (param i32)))
  (type (;2;) (func (param i32) (result i32)))

  (import "wasi_snapshot_preview1" "fd_close" (func $__wasi_fd_close (type 2)))
  (import "wasi_snapshot_preview1" "proc_exit"
    (func $__wasi_proc_exit (type 1))
  )

  (func $_start (type 0)
    (call $__wasi_fd_close (i32.const 0))
    call $__wasi_proc_exit
  )

  (memory (;0;) (export "memory") 1)

  (export "_start" (func $_start))
)

Running the compiled .wasm file on other runtimes return a 0 status code indicating success. But running this on SSVM gives me status code 58. Any idea why?

Expected

ssvm a.wasm --memory-limit=4G

# if a.wasm uses more than 4G, killed

Today's WasmEdge host functions are statically compiled and linked to the VM binary.

In the future, we would like to support a dynamic mechanism to register custom host functions in a running WasmEdge instance.

https://github.com/WebAssembly/tail-call

https://github.com/webassembly/threads

We would like to embed WasmEdge in our product to make it easier for users to extend it.

Users can upload their WASM code to our server and we will create WASM VMs to execute the code.

We expect the execution time of the user code to be short, however, we cannot detect and eliminate dead loops before the execution. So it would be a great help if the execution could be interrupted, and in our case, we don't need to resume the execution after the interruption.

Some WASM runtime leverage 'gas' to limit the execution time, but this doesn't fulfill our requirement as the timeout duration can not be known before the execution in some cases.

A related nice to have feature is "reset a VM": a VM is left at an unpredictable state after an interruption, which makes it unusable and we will have to create a new VM to replace it. We assume reset a VM to its initial state cost much lesser time than creating a new VM and think it can help improve our performance.

I follow build-ssvm to build at master branch in this command:

docker run --rm -w /ssvm secondstate/ssvm bash -c \
    "git clone --depth 1 https://github.com/second-state/SSVM.git . && mkdir -p build && cd build && cmake -DCMAKE_BUILD_TYPE=Release -DBUILD_TESTS=ON .. && make -j"

But it fails with error, here is log:

[ 81%] Building CXX object lib/vm/CMakeFiles/ssvmVM.dir/vm.cpp.o
[ 82%] Building CXX object tools/ssvm/CMakeFiles/ssvmc.dir/ssvmc.cpp.o
[ 83%] Building CXX object test/aot/CMakeFiles/ssvmAOTWagonTests.dir/AOTwagonTest.cpp.o
[ 84%] Linking CXX executable ssvmLoaderEthereumTests
[ 85%] Linking CXX executable ssvmASTTests
In file included from /ssvm/tools/ssvm/ssvmc.cpp:5:
/ssvm/build/include/common/version.h:22:5: error: use of undeclared identifier 'CPACK_PACKAGE_VERSION'
    CPACK_PACKAGE_VERSION;
    ^
1 error generated.
make[2]: *** [tools/ssvm/CMakeFiles/ssvmc.dir/build.make:63: tools/ssvm/CMakeFiles/ssvmc.dir/ssvmc.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:2373: tools/ssvm/CMakeFiles/ssvmc.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
[ 86%] Linking CXX executable ssvmLoaderWagonTests
[ 87%] Linking CXX executable ssvmProcessTests
[ 88%] Linking CXX executable wasiTests
[ 88%] Built target ssvmLoaderFileMgrTests
[ 89%] Linking CXX executable ssvmAOTWagonTests
[ 90%] Linking CXX static library libssvmVM.a
[ 90%] Built target ssvmLoaderEthereumTests
[ 90%] Built target ssvmVM
[ 90%] Built target ssvmLoaderWagonTests
[ 90%] Built target ssvmProcessTests
[ 90%] Built target ssvmASTTests
[ 90%] Built target wasiTests
[ 90%] Built target ssvmAOTWagonTests
make: *** [Makefile:163: all] Error 2

Is there anything wrong with the command?

Motivation

See the discussion in #341 , #341 (comment)

Currently, the wasmedge.h.in is synced with errcode.h manually. This is not good, we should avoid relying on human to sync code.

Expected

Create a checker, a helper tool, or split the wasmedge.h.in to multiple and sync from errcode.h directly.

When building with cmake -DCMAKE_BUILD_TYPE=Release -DWASMEDGE_BUILD_AOT_RUNTIME=OFF .. (as instructed in doc/build.md), I got the following error message:

[ 98%] Building CXX object lib/api/CMakeFiles/wasmedge_c.dir/wasmedge.cpp.o
/root/WasmEdge/lib/api/wasmedge.cpp: In function 'WasmEdge_CompilerContext* WasmEdge_CompilerCreate(const WasmEdge_ConfigureContext*)':
/root/WasmEdge/lib/api/wasmedge.cpp:754:58: error: unused parameter 'ConfCxt' [-Werror=unused-parameter]
  754 | WasmEdge_CompilerCreate(const WasmEdge_ConfigureContext *ConfCxt) {
      |                         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~
/root/WasmEdge/lib/api/wasmedge.cpp: In function 'WasmEdge_Result WasmEdge_CompilerCompile(WasmEdge_CompilerContext*, const char*, const char*)':
/root/WasmEdge/lib/api/wasmedge.cpp:767:31: error: unused parameter 'Cxt' [-Werror=unused-parameter]
  767 |     WasmEdge_CompilerContext *Cxt, const char *InPath, const char *OutPath) {
      |     ~~~~~~~~~~~~~~~~~~~~~~~~~~^~~
/root/WasmEdge/lib/api/wasmedge.cpp:767:48: error: unused parameter 'InPath' [-Werror=unused-parameter]
  767 |     WasmEdge_CompilerContext *Cxt, const char *InPath, const char *OutPath) {
      |                                    ~~~~~~~~~~~~^~~~~~
/root/WasmEdge/lib/api/wasmedge.cpp:767:68: error: unused parameter 'OutPath' [-Werror=unused-parameter]
  767 |     WasmEdge_CompilerContext *Cxt, const char *InPath, const char *OutPath) {
      |                                                        ~~~~~~~~~~~~^~~~~~~
cc1plus: all warnings being treated as errors

Versions

• WasgmEdge: master (c4452d778636d3af207a0602dbec6276b8099847)
• Docker image: wasmedge/wasmedge:ubuntu-build-gcc (04cd593f0f1e)

Motivation

Machine Learning is a big topic nowadays. WasmEdge already provides a set of TensorFlow host functions to enable the ML inference in WebAssembly. However, these TensorFlow host functions are defined by us and they are just a Wasm function binding from the TensorFlow C API.

Here comes a standard, the WASI-NN proposal provides a new way to perform neural network inferencing by using a runtime-provided implementation that can leverage host native optimizations, CPU multi-threading, or powerful hardware devices such as GPUs or TPUs.

Specification

1. Follow the Spec of WASI-NN proposal
2. Implement related host functions in WasmEdge.
3. Add unit tests and coverage to these functions.
4. Take OpenVINO as WASI-NN backend and create a demo kit that is similar to Wasmtime

Appendix

1. WasmEdge TensorFlow rust SDK: https://github.com/second-state/wasmedge_tensorflow_interface
2. WasmEdge TensorFlow host functions: https://github.com/second-state/WasmEdge-tensorflow
3. TensorFlow C API: https://github.com/tensorflow/tensorflow/blob/master/tensorflow/c/c_api.h
4. WASI-NN proposal: https://github.com/WebAssembly/wasi-nn
5. Implementing-wasi-nn-in-wasmtime: https://bytecodealliance.org/articles/implementing-wasi-nn-in-wasmtime

WasmEdge needs to support the wasm-proxy spec in order to be used in service mesh proxies like Envoy and MOSN.

https://github.com/proxy-wasm/spec

As an SRE person I need to have the capability to monitor, trace and report the performance of my workloads that are running on the edge. Thus, this can be achieved by adding:

• Allow/provide the capability of logging in (opentelemetry-specification)[https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/overview.md]
• Allow/provide the capability of tracing in (opentelemetry-specification)[https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/overview.md]
• Allow/provide the capability of metrics reporting by having a node exporter and/or expose [/healthz, /metrics] endpoints
  Ex: https://github.com/boxkite-ml/boxkite/tree/master/boxkite/monitoring
  thank you

Wasmedge 0.8.2-rc4

I try build a wasm with grain

csh@MSI:/mnt/c/Users/45876/Desktop/wasm/gr$ wavm run main.gr.wasm
random
-770626366
time
<unknown boxed number>
<unknown boxed number>
<unknown boxed number>
<unknown boxed number>
Process
[> "main.gr.wasm"]
[> ]
csh@MSI:/mnt/c/Users/45876/Desktop/wasm/gr$ wasmedge-0.8.2 main.gr.wasm
[2021-08-20 00:00:57.502] [error] instantiation failed: incompatible import type, Code: 0x61
[2021-08-20 00:00:57.503] [error]     Mismatched function type. Expected: params{i32 , i32 , i32 , i32 , i64 , i64 , i32} returns{i32} , Got: params{i32 , i32 , i32 , i32 , i32 , i32 , i32} returns{i32}
[2021-08-20 00:00:57.504] [error]     When linking module: "wasi_snapshot_preview1" , function name: "path_filestat_set_times"
[2021-08-20 00:00:57.504] [error]     At AST node: import description
[2021-08-20 00:00:57.505] [error]     At AST node: import section
[2021-08-20 00:00:57.505] [error]     At AST node: module
csh@MSI:/mnt/c/Users/45876/Desktop/wasm/gr$

SSVM is really nice! I particularly like the ONNC support. Would it be possible to add a minimal example that demonstrates how to get from an ONNX model to running it with ssvm-qitc?

I use fibonacci.wasm to write a simple benchmark between SSVM and node.
In my computer(WSL), fib 40 cost 40s in SSVM but 1s in node. Any idea or reason for that?

cc @eee4017

I build a wasi-quickjs (use wasi-sdk 12). but when I run it on wasmEdge.

$ wasmedge qjs.wasm -h
[2021-08-02 01:22:46.053] [error] instantiation failed: incompatible import type, Code: 0x61
[2021-08-02 01:22:46.058] [error]     Mismatched function type. Expected: params{i32 , i32 , i32 , i32 , i32 , i32} returns{i32} , Got: params{i32 , i32 , i32 , i32 , i32} returns{i32}
[2021-08-02 01:22:46.060] [error]     When linking module: "wasi_snapshot_preview1" , function name: "path_readlink"
[2021-08-02 01:22:46.063] [error]     At AST node: import description
[2021-08-02 01:22:46.064] [error]     At AST node: import section
[2021-08-02 01:22:46.065] [error]     At AST node: module

on wasmer

$ wasmer run qjs.wasm -- -h
QuickJS version 1.0.0
usage: qjs [options] [file [args]]
-h  --help         list options
-e  --eval EXPR    evaluate EXPR
-i  --interactive  go to interactive mode
-m  --module       load as ES6 module (default=autodetect)
    --script       load as ES6 script (default=autodetect)
-I  --include file include an additional file
    --std          make 'std' and 'os' available to the loaded script
-T  --trace        trace memory allocation
-d  --dump         dump the memory usage stats
    --memory-limit n       limit the memory usage to 'n' bytes
    --unhandled-rejection  dump unhandled promise rejections
-q  --quit         just instantiate the interpreter and quit

We use Python to call tensorflow to detect yolov3. We are preparing to migrate it to wasmedge. The developer can refer to this document for verification（ https://www.secondstate.io/articles/faas-image-classification/ ）
But there are some problems:

When using yolov3 detection, you need to import a piece of code of model.py in yolov3 when importing the model
And then Yolo_ model.load_ weights(self.model_ Path) can be imported into the model. I don't know how to convert this into a rust code.

There is also the need to generate a filtered bounding box boxes (this is a tensor tensor) in advance during detection
boxes: Tensor("concat_11/concat:0", shape=(None, 4), dtype=float32),There are also scores and classes
socres: Tensor("concat_12/concat:0", shape=(None,), dtype=float32)
classes: Tensor("concat_13/concat:0", shape=(None,), dtype=int32)，
The three tensors are generated by Yolo in model. py The three results are fixedThree variables need to be input when sess. Run()
and I don't know how to write this as trust.

model.py code：https://github.com/qqwweee/keras-yolo3/tree/master/yolo3

can't find 0.7.3

Motivation

After WasmEdge provides an experimental API, WASI Socket, for supporting Berkeley Sockets API in Wasm. WasmEdge enabled a new way to open a new socket, listen to an existed socket, and send and receive data. Moreover, it will be nice if we can do more things in the related features such as SSL support.

To achieve this feature, one possible way is to compile the OpenSSL library to Wasm and link it as a library. However, the performance may be not good, because all the computation jobs are done at the wasm level. Here is an alternative way, instead of the previous one, we can wrap the OpenSSL library to Wasm external functions. For example, binding ssl_connect to (import "openssl" "ssl_connect" ... ). Unfortunately, this is not an easy way to do it.

To simply the workload, we decide to implement the WASI-crypto proposal first, and then use this proposal to make the above things happen.

Specification

1. Follow the spec of WASI-crypto proposal.
2. Implement the interface functions in WasmEdge wasi-crypto modules.
3. Add unit tests and coverage to related functions.
4. Create a demo kit to show the WASI-Crypto features.

Appendix

1. WASI-Crypto: https://github.com/WebAssembly/wasi-crypto
2. WASI-Crypto Rust SDK: https://github.com/WebAssembly/wasi-crypto/tree/main/implementations/bindings/rust

This is a nice thing to have

We should have a document for telling people the relationships between SSVM and its ecosystem.

Create a new repository which contains the WASI Socket API for the Rust language.

Currently CMake enables all targets, including ssvm-aot, which requires llvm.

It would be nice to have the ability to only build the interpreter and not depending on llvm in that case.

Prior to Rust 1.50, the wasm32-wasi and wasm32-unknown-unknown compiler targets both generate bytecode compatible with wasm-bindgen. However, a change in Rust 1.50’s wasm32-wasi compiler backend has broke wasm-bindgen compatibility.

But, many WasmEdge customers and users are using both wasm32-wasi and wasm-bindgen features, especially when WasmEdge programs are embedded in Node.JS and golang host applications. That is broken in Rust 1.51 and above.

As a temporary solution, the rustwasmc tool will ask you to set your Rust compiler version to 1.50 except for the following.

• If the source application is a standalone main.rs program, rustwasmc will use any Rust version with the wasm32-wasi backend. The reason is that wasm-bindgen does not apply to standalone wasi programs.
• If you explicitly override rustwasmc to use the wasm32-unknown-unknown backend, it will use any Rust compiler version. In this case, the resulting bytecode will be compatible with wasm-bindgen but not wasm32-wasi.

A long-term solution is to support the wasm interface types proposal. It allows host applications to pass complex data types to WASI programs in the same way as wasm-bindgen.

Hello,
I tried to use the secondstate/ssvm docker image with these commands:
"$ docker pull secondstate/ssvm:dev-0.3.0" ,and "docker pull secondstate/ssvm"
But I always recieve an Error:"Error response from daemon: manifest for secondstate/devchain:latest not found: manifest unknown: manifest unknown"
I want to know if the docker image is available? Thank you~

Motivation

The wasm-Signature proposal is specifically about embedded digital signatures in WebAssembly modules, not about package/OCI signatures. When distributing WebAssembly modules, it will be nice if we can have a way to verify.

To achieve this target, we choose a Wasm-Signature proposal as our implementation standard. With this proposal, WasmEdge can provide sign and verify features.

Specification

1. Follow the Spec of Wasm-Signature proposal.
2. Please use the Options (b) Sign all bytecode preceding the “signature” Section as our solution.
3. Implement the sign and verify features in the WasmEdge command line tool.
4. Add unit tests and coverage to the related functions.
5. Create a demo kit:

# Sign
wasmedge sign --key signerkey.pem --output signed-module.wasm input-module.wasm
# Verify
wasmedge verify --key signerkey.pub.pem signed-module.wasm
# Return 0 if ok, otherwise, return 1 with error messages

Appendix

1. Wasm-Signature: https://github.com/wasm-signatures/design
2. Existed tool, WasmSign: https://github.com/jedisct1/wasmsign
3. Existed tool, wasm-sign: https://github.com/frehberg/wasm-sign

Hi,

Thanks for sharing such a nice project.

I was having a look at the AOT compiler and noticed that a wrapper is created for each WebAssembly function.

I am wondering what is the motivation behind this?

Cheers

After we released the 0.8.1, our WasmEdge C API provides fully support of compiler and runner.

It would be great if we can support Wasm-C-API also.