181–190 of 265 posts
Stupid question from a non specialist. I see Intel in the list of parties. Does that mean hardware acceleration for wasm?
Among other things, yes; we're contributing to the SIMD support, for instance.
And that was years ago.
Seems like an awful waste to have many millions of cpus with avx for instance, wasted.
Earlier quoted context omitted.
It is meant to be compiled to native instructions, I don't think there is significant room for hardware acceleration.
I am talking from a position of ignorance, but intuitively I am sure the runtime does or will do lots of things, between the sandboxing, the linking, potential garbage collection, etc.
Earlier quoted context omitted.
Can you link to an example of this exploit? Does javascript suffer from the same problem?
Any kind of typical C memory corruption that you can think of that fails to validate the buffer sizes that you give as parameters. WebAssembly memory access bytecodes only do bounds checking of the linear memory block that gets allocated to the module. You then do your own memory management taking subsets from that memory block and assigning it to the respective internal heap allocations or global memory blocks. So y…
Earlier quoted context omitted.
Reading through this, this sounds like mostly a capability based architecture, with process isolation replaced with a statically typed bytecode in which you can verify that each module can only use capabilities passed to it. I was wondering why the focus on copying memory between the processes. It should be possible to make capabilities which represent a pointer and a length (and maybe an access mode), which could be…
What you're describing will indeed be introduced with the WebAssembly GC proposal: https://github.com/WebAssembly/gc For languages that can express unforgeable pointers as first-class concept, that is indeed a very attractive, fine-grained approach. Unfortunately bringing that to languages like C/C++/Rust is a different matter altogether. Since we want to support those languages as first-class citizens, we can't requ…
I feel like you're overthinking it. Can't you just have a table that holds GCable objects and only hand out indexes to C and co?
Earlier quoted context omitted.
What you're describing will indeed be introduced with the WebAssembly GC proposal: https://github.com/WebAssembly/gc For languages that can express unforgeable pointers as first-class concept, that is indeed a very attractive, fine-grained approach. Unfortunately bringing that to languages like C/C++/Rust is a different matter altogether. Since we want to support those languages as first-class citizens, we can't requ…
> For languages that can express unforgeable pointers as first-class concept, that is indeed a very attractive, fine-grained approach. Unfortunately bringing that to languages like C/C++/Rust is a different matter altogether. The semantics of these languages aren’t incompatible with unforgeable references, though: it generally works in practice, but it’s technically undefined to create pointers out of thin air. Why c…
Stupid question from a non specialist. I see Intel in the list of parties. Does that mean hardware acceleration for wasm?
I'm one of the folks working with the Alliance, and I'm incredibly excited about WebAssembly outside the browser. Happy to answer questions. Imagine extensions for applications or databases, written in any language you want, with no ability to exfiltrate data. Imagine supporting a safe plugin API that isn't just for C and languages that FFI to C, but works natively with safe datatypes. Today, if you want to be extens…
> Imagine embedding a WebAssembly runtime like wasmtime, and telling people they can write their extensions in any language they want. Is that desirable? Won't it lead to a bloated mess with every extension dragging in a different language runtime with it?
Earlier quoted context omitted.
Actually it fails to properly sandbox C derived languages versus what hardware memory tagging like SPARC ADI and ARM are capable of, because it doesn't do bounds checks inside linear memory blocks.
Hardware memory tagging is not a requirement for sandboxing. Actually, hardware memory tagging doesn’t even fully restrict out-of-bounds accesses because it’s granularity is usually larger than a byte.
Even if they would be at word level, it is already an improvement over the actual design.
Earlier quoted context omitted.
That is exactly the point, don't advertise WebAssembly as safe bytecode, if unsafe languages are part of the picture without any kind of control. Secondly, nor ISO C or ISO C++ forbid implementations that do bounds checking by default. In fact that is what most modern compilers do by default in debug mode. Finally look at memory tagging in Solaris SPARC ADI, Apple iOS or the upcoming ARM extensions support on Android…
The point of the byte code being safe is that no operations performed by WASM code could cause a memory unsafety bug from the perspective outside the sandbox. If your code violates its own memory rules then it will only mess up the logical state of its VM memory chunk, and probably produce an incorrect result. The same thing can happen in any safe language if you access the wrong indexes in an array because of a logi…
So hand waving such security issues is rather strange, when it should be the top concern when selling an infrastructure to run code from unknown sources.
Earlier quoted context omitted.
That is exactly the point, don't advertise WebAssembly as safe bytecode, if unsafe languages are part of the picture without any kind of control. Secondly, nor ISO C or ISO C++ forbid implementations that do bounds checking by default. In fact that is what most modern compilers do by default in debug mode. Finally look at memory tagging in Solaris SPARC ADI, Apple iOS or the upcoming ARM extensions support on Android…
> In fact that is what most modern compilers do by default in debug mode. Assuming that “debug mode” is -g or equivalent, then I have not seen a modern compiler that does this.
Or Solaris SPARC and iOS compilers that make use of hardware memory tagging.
Clang and GCC do need extra flags to enable FORTIFY mode though.
However on Android FORTIFY is now a requirement and future versions will make use of memory tagging on ARM hardware.
So ironically something like Android does have a better sandboxing model as WebAssembly.