Stupid question from a non specialist. I see Intel in the list of parties. Does that mean hardware acceleration for wasm?
It is meant to be compiled to native instructions, I don't think there is significant room for hardware acceleration.
The Bytecode Alliance: Building a secure, composable future for WebAssembly
131–140 of 265 posts
Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly
#132So much bullshit, in the end just to strip a little bit more the user and the developer of any liberty. The dream of us corp controlled appstore for pc desktops. Who will control what you can do through the sandbox? Intel, Mozilla, Google... So one day your soft will have to be signed by them and will refuse to let you adblock ... For your own safety...
When you use WebAssembly, you're in control of the sandbox. You can pass things into the sandbox and let the module use it. There's no signing/certificate/appstore system tied to WebAssembly.
How is this different from current web browsers for running JavaScript apps? Don't you think there is lockdown now?
Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly
#133Can you use wasm instead of regular js/html? I'm thinking for rich GUIs it would be great, even just for company internal sites. I can't find any good examples though.
Rust has libraries for this.
Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly
#134Wait... I thought the CLR was supposed to do this? Or was it the JVM? What's old is new again!
Or UNCOL, or Xerox Pilot and Dorado microcoded CPUs, or IBM z/OS and OS/400 language environments, or VMS multi-language backends, or PNaCL, or ....
Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly
#135Stupid 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.
Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly
#136Stupid question from a non specialist. I see Intel in the list of parties. Does that mean hardware acceleration for wasm?
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.
Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly
#137First of all, congrats on forming the alliance! > Imagine extensions for applications or databases, written in any language you want, with no ability to exfiltrate data That's what we are working towards on Wasmer, the server side WebAssembly runtime - https://github.com/wasmerio/wasmer In fact, we already have a lot of different language integrations (maintained by us and the community) and our software is the pione…
> First of all, congrats on forming the alliance! No Google on board, it means no Chrome support
What does Chrome have to do with a plugin for my image editor or a command line tool on my server?
Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly
#138I'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?
Web developers don't seem to have any concern about using gigantic quantities of memory. Don't hire a web developer to develop for games. :)
Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly
#139Earlier quoted context omitted.
There will be ways to memory-map files, share memory between modules, and otherwise avoid copying memory unnecessarily. Shared memory doesn't break the sandbox. Sharing all memory by default would, but controlled sharing of specific memory doesn't. Think of it like inter-process shared memory, rather than threads sharing an entire address space.
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 require GC support as a base concept, so we have to treat a nanoprocess as the unit of isolation from the outside.
Once we have GC support, nothing will prevent languages that can use it from expressing finer-grained capabilities even within a nanoprocess, and that seems highly desirable indeed.
(full disclosure: I'm a Mozilla employee and one of the people who set up the Bytecode Alliance.)
Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly
#140Earlier quoted context omitted.
WebAssembly also has its security issues. Lack of bounds checking for multiple data accesses mapped to the same linear memory block.
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 you just need to have a couple of structs or C string/arrays, living alongside each other and overwrite one of them by writing too much data due to miscalculations of the memory segment holding the data.