4 ms·

Probably dumb q - are there security implications of using aot for untrusted workloads? Are there plans to do jit?

evacchi 3y ago
It depends on what you mean for JIT. wazero is load-time AoT; i.e. we compile the module in-memory on load, for efficient execution later, when you instantiate, it is not AoT in the sense that we produce a stand-alone executable, the runtime is always hosting that executable code that is generated, and we go back-and-forth between translated wasm and "Go space" at run-time in many cases. It is AoT in the sense that we do not tune the generated code depending on tracing or profiling information, because we don't track it for compilation. The Wasm model itself gives a certain degree of safety: e.g. you do not have complete control over the host OS, because you have to explicitly expose functions to the gues module; we also provide a certain degree of control over e.g. execution time (you can instantiate a module in such a way that executions can be cancelled or set a timeout) and memory space. We also provide an interpreter for all platforms where Go runs, and Takeshi (the founder of the project) is also working on bootstrapping an optimizing compiler that should soon land on main, and more work will happen in that space.
- carom 3y ago
  Does the AoT compiler target Go's assembly language or do you have arch specific targets?
  - evacchi 3y ago
    we have our own assembler for arm64 and asm64
circuit10 3y ago
JIT/AOT just refers to the time that compilation is done, it doesn’t necessarily have anything to do with security.
- dilyevsky 3y ago
  It does when you hadn’t built the .wasm yourself. Example: https://github.com/WasmEdge/WasmEdge/issues/1631 https://github.com/WasmEdge/WasmEdge/issues/1631
  - circuit10 3y ago
    That’s a bug/oversight in a specific VM implementation. A JIT with a code cache (like V8) could have the same type of bug. It says nothing about about the inherent security of JIT vs AOT

It depends on what you mean for JIT. wazero is load-time AoT; i.e. we compile the module in-memory on load, for efficient execution later, when you instantiate, it is not AoT in the sense that we produce a stand-alone executable, the runtime is always hosting that executable code that is generated, and we go back-and-forth between translated wasm and "Go space" at run-time in many cases. It is AoT in the sense that we do not tune the generated code depending on tracing or profiling information, because we don't track it for compilation. The Wasm model itself gives a certain degree of safety: e.g. you do not have complete control over the host OS, because you have to explicitly expose functions to the gues module; we also provide a certain degree of control over e.g. execution time (you can instantiate a module in such a way that executions can be cancelled or set a timeout) and memory space. We also provide an interpreter for all platforms where Go runs, and Takeshi (the founder of the project) is also working on bootstrapping an optimizing compiler that should soon land on main, and more work will happen in that space.

carom 3y ago
Does the AoT compiler target Go's assembly language or do you have arch specific targets?
- evacchi 3y ago
  we have our own assembler for arm64 and asm64

circuit10 3y ago

JIT/AOT just refers to the time that compilation is done, it doesn’t necessarily have anything to do with security.

dilyevsky 3y ago
It does when you hadn’t built the .wasm yourself. Example: https://github.com/WasmEdge/WasmEdge/issues/1631 https://github.com/WasmEdge/WasmEdge/issues/1631
- circuit10 3y ago
  That’s a bug/oversight in a specific VM implementation. A JIT with a code cache (like V8) could have the same type of bug. It says nothing about about the inherent security of JIT vs AOT