Hacker News Reader

Comment by pizlonator | Hacker News Reader

That's a sandboxing technology but not a memory safety technology.

You can totally achieve weird execution inside the rlbox.

Running ffmpeg compiled for wasm and watching as most codec selections lead to runtime crashes due to invalid memory accesses is fun. But, yeah, it’s runtime safety, so going to wasm as a middle step doesn’t do much.

> Running ffmpeg compiled for wasm and watching as most codec selections lead to runtime crashes due to invalid memory accesses is fun.

For all you know that’s a bug in the wasm port of the codec.

> it’s runtime safety

So is Fil-C

The problem with wasm is that an OOBA in one C allocation in the wasm guest can still give the attacker the power to clobber any memory in the guest. All that’s protected is the host. That’s enough to achieve weird execution.

Hence why I say that wasm is a sandbox. It’s not memory safety.

I’m not disagreeing with anything you said about wasm?

Finally reality is catching up with the WASM sales pitch against other bytecode formats introduced since 1958, regarding security and how great it is over anything else.

Warm was great because it was lightweight and easy to target from any language and create any custom interaction API with the host. That's becoming less true as they bolt on features no one needed (GC) and popularize standardized interfaces that contain the kitchen sink (WASI) but these things can still be treated as optional so it can still be used for much more flexible use cases than java or .net

Since 1958 (UNCOL) there have been more options than only Java or CLR MSIL.

There’s no guarantee the toolchains will support WASM “preview” forever and make the bloat optional, and even if they do you could still end up in an ecosystem where it would be unviable. At some point you’re probably better off just compiling to RISCV and using an emulator library instead.

Fortunately core wasm is simple enough for a single person to implement an interpreter or even compiler for.

Even if the major engines continue to pile on complexity we have a pretty good escape hatch I think.

> features no one needed (GC)

WasmGC is absolutely necessary for languages like Dart, Kotlin, and Java, which are all using it right now successfully.

But I get that if you're compiling C or Rust then it might seem like it isn't useful.

Wasm now supports multiple modules and multiple linear memories per module, so it ought to be quite possible to compile C to Wasm in a way that enforces C's object access rules, much like CHERI if perhaps not Fil-C itself.

You wouldn't be able to get quite as fine-grained. One memory per object is probably horrifically slow. And I don't know about Fil-C, but CHERI at least allows capabilities (pointers with bounds) to overlap and subset each other. I.e. you could allocate an arena and get a capability for that, and then allocate an object inside that arena and get a smaller capability for that, and then get a pointer to a field in that object and get capability just for that field.

One would probably just need to define WASM extensions that allow for such subsetting. Performance will probably be competitive with software implementations of CHERI (perhaps with varying levels of hardware acceleration down the road) which isn't that bad.

Fil-C has like one "linear memory" per object and each capability gives read/write access to the whole object.

But Fil-C has its compiler which does analysis passes for eliding bounds-checks where they are not needed, and I think it could theoretically do a better job at that than a WASM compiler with multi-memories, because C source code could contain more information. Unlike WASM, but like CHERI, every pointer in memory is also tagged, and would lose its pointer status if overwritten by an integer, so it is still more memory-safe in that way.

It has a separate address space for each object? That seems unlikely. Is it not pretty much a software implementation of CHERI?

Some WebAssembly runtimes now do support those parts of the specification.

The multiple linear memory is supported in wasi preview 3? I thought it was not supported as of preview 2.

Reply on news.ycombinator.com