The statement is correct. Wasm cannot mark memory as executable. It's effectively a Harvard Architecture. The code and memory are split. Furthermore you cannot jump to arbitrary points in code. There isn't even a jump instruction.
> I'm quite convinced the alleged security argument is bull. You can hot reload JS (or even do wilder things like codegen) at runtime without compromising security.
JIT here is referring to compiling native code at runtime and executing it. This would be a huge security compromise in the browser or in a wasm sandbox.
> I don't see any technical reason why this couldn't be possible. If this were a security measure, it could be trivially bypassed.
> Also, WASM bytecode is very similar conceptually to .NET IL, Java bytecode etc., things designed for JIT compilation.
Yes, and like with Wasm, the engine is responsible for JITting. But giving the user the power to escape the runtime and emit native code and jump to it is dangerous.
wasm has no way to remap writable memory as executable, but you can absolutely call back into javascript to instantiate and link a new executable module, like https://github.com/remko/waforth does.
Yes, I understand that you can do anything with imports. But that's not part of the Wasm spec. That's a capability the host has decided to give the module. Of course the person with the most privilege can always open holes up, but that capability is not there by default.
> I'm quite convinced the alleged security argument is bull. You can hot reload JS (or even do wilder things like codegen) at runtime without compromising security.
JIT here is referring to compiling native code at runtime and executing it. This would be a huge security compromise in the browser or in a wasm sandbox.
> I don't see any technical reason why this couldn't be possible. If this were a security measure, it could be trivially bypassed.
It's not because it's baked into the design and instruction set. You can read some more about how it works here: https://webassembly.org/docs/security/
> Also, WASM bytecode is very similar conceptually to .NET IL, Java bytecode etc., things designed for JIT compilation.
Yes, and like with Wasm, the engine is responsible for JITting. But giving the user the power to escape the runtime and emit native code and jump to it is dangerous.