Comment by burakemir | Hacker News Reader

Comment by burakemir | Hacker News Reader

My trouble with separate categories "memory safety technology" and "sandboxing technology" is that something like WASM execution is both:

* Depending on how WASM is used, one gets safety guarantees. For example, memory is not executable.

* Privileges are reduced as a WASM module interacts with the environment through the WASM runtime and the embedder

Now, when one compiles C to WASM one may well compile things with bugs. A memory access bug in C is still a memory access bug, but its consequences can be limited in WASM execution. Whether fail-stop behavior is guaranteed actually depends on the code the C compiler generates and the runtime (allocation/deallocation, concurrency) it sets up.

So when we enumerate immediately available security options and count WASM as sandboxing, this is not wrong. But WASM being an execution environment, one could do a lot of things, including a way of compiling and executing C that panics when a memory access bug is encountered.

Wasm is just sandboxing.

Say your C program has sensitive information in module A and a memory safety bug in module B. Running that program in wasm won’t prevent the attacker from using the bug in B to get read/write access to the data in A.

In practice what the attacker will really do is use the memory safety bug to achieve weird execution: even without control over the program counter, the fact that a memory safety bug inside the wasm memory gives read write access to all of that memory means the attacker can make the program do whatever they want, subject to the wasm sandbox limits (ie whatever the host allows the wasm guest to do).

Basically wasm amounts to a lightweight and portable replacement for running native code in a sufficiently sandboxed process

Your general point stands - wasm's original goal was mainly sandboxing - but

1. Wasm does provide some amount of memory safety even to compiled C code. For example, the call stack is entirely protected. Also, indirect calls are type-checked, etc.

2. Wasm can provide memory safety if you compile to WasmGC. But, you can't really compile C to that, of course...

Correct me if I'm wrong, but with LLVM on Wasm, I think casting a function pointer to the wrong type will result in you calling some totally unrelated function of the correct type? That sounds like the opposite of safety to me.

I agree about the call stack, and don't know about GC.

That is incorrect about function pointers: The VM does check that you are calling the right function type, and it will trap if the type does not match.

Here it is in the spec:

> The call_indirect instruction calls a function indirectly through an operand indexing into a table that is denoted by a table index and must have type funcref. Since it may contain functions of heterogeneous type, the callee is dynamically checked against the function type indexed by the instruction’s second immediate, and the call is aborted with a trap if it does not match.

From https://www.w3.org/TR/wasm-core-2/#syntax-instr-control

(Other sandboxing approaches, including related ones like asm.js, do other things, some closer to what you mentioned. But wasm has strict checking here.)

Hmm, I wonder if I was confusing emscripten's asm.js approach with its approach to Wasm. Thank you!

Depends on how it is used is already a sign that WebAssembly isn't really as safe as being sold, by many of its advocates, versus other bytecode formats.

Like, C is actually really safe, it only depends on how it is being used.

People only have to enumerate the various ways and tools to write safe code in C.

Problem solved, or so we get to believe.

WASM is just a bytecode format for a stack based vm. Granted it is weirdly named, the actual "Assembly" equivalent is WAT.

But the point is, it is a format specification, which has nothing to do with safety. You can implement a totally unsafe WASM runtime if you so choose. Personally I think it's not a bad thing, at least we have something like it that can run in a browser environment. But I am curious to know why you dislike it so much.

> including a way of compiling and executing C that panics when a memory access bug is encountered.

WASM couldn’t do that because it doesn’t have a sense of the C memory model nor know what is and isn’t safe - that information has long been lost. That kind of protection is precisely what Fil-C is doing.

WASM is memory safe in that you can’t escape the runtime. It’s not memory safe in that you can escape escape the program running within the sandbox, which you can’t do with a memory safe language like Rust or Fil-C.

Reply on news.ycombinator.com