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

You can totally achieve weird execution inside the rlbox.

ComputerGuru 21 hours ago | parent | next [-]

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.

▲

pizlonator 21 hours ago | parent | next [-]

> 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.

	▲	ComputerGuru 20 hours ago \| parent [-]
		I’m not disagreeing with anything you said about wasm?

▲

14 hours ago | parent | prev | next [-]

[deleted]

▲

pjmlp 13 hours ago | parent | prev [-]

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.

▲

singpolyma3 10 hours ago | parent [-]

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

▲

azakai an hour ago | parent | next [-]

> 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.

▲

mhjkl 5 hours ago | parent | prev | next [-]

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.

	▲	apitman 3 hours ago \| parent [-]
		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.

▲

pjmlp 10 hours ago | parent | prev [-]

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

▲

zozbot234 15 hours ago | parent | prev [-]

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.

▲

pjmlp 10 hours ago | parent | next [-]

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

▲

IshKebab 14 hours ago | parent | prev [-]

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.

▲

Findecanor 9 hours ago | parent | next [-]

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.

	▲	IshKebab 7 hours ago \| parent [-]
		It has a separate address space for each object? That seems unlikely. Is it not pretty much a software implementation of CHERI?

▲

zozbot234 10 hours ago | parent | prev [-]

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.