threads
multi-memory
Our great sponsors
threads | multi-memory | |
---|---|---|
16 | 6 | |
668 | 115 | |
2.7% | 7.0% | |
2.0 | 3.7 | |
4 months ago | 10 months ago | |
WebAssembly | WebAssembly | |
GNU General Public License v3.0 or later | GNU General Public License v3.0 or later |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
threads
-
No installation required: how WebAssembly is changing scientific computing
Similarly for threads: https://github.com/webassembly/threads
-
WebAssembly: Adding atomics waits to the main thread is the right thing to do
Specifically I submitted this to draw attention to the latest comment in the thread: https://github.com/WebAssembly/threads/issues/177
It's a good deep dive into how a small, but well-intentioned, browser choice nearly a decade ago led to poor outcomes for the WebAssembly ecosystem.
-
WASI Support in Go
The answer is: it's complicated. Which is most of the time the answer in the WASI world.
For this case it's complicated because some runtime supports https://github.com/WebAssembly/threads which mostly contains things like the spec for atomic but not the actual "threads" specs and then some runtimes (i.e wasmtime) also supports https://github.com/WebAssembly/wasi-threads which is one version of the threads. But a new proposal came into play https://github.com/abrown/thread-spawn so ... it's complicated.
-
WASM is the future?
There’s a proposal for threads
- Bringing Git in the browser via Go and WebAssembly. Upload, create files, folders, branches, commits etc... On the fly in the browser
-
LibreOffice running natively in a browser via WebAssembly
WebAssembly is having/going to have threads
https://github.com/WebAssembly/threads
-
The State of WebAssembly â 2021 and 2022
It's disappointing to see the WebAssembly/threads proposal is still only in proposal state, despite existing since 2018. It being just a proposal stops languages like golang from actually implementing support for it, despite Chrome supporting it since v70.
-
Using WebAssembly threads from C, C++ and Rust
Ah, I should have clarified that I mean the assembly instructions for atomics, rather than the JavaScript API. I.e. the opcodes listed here: https://github.com/WebAssembly/threads/blob/master/proposals...
-
AMA: We are Akhi, Alexandra, Islam, and Dimitris from the DFINITY Execution team. Ask us anything about building the execution layer.
Another point to add here is that the current wasm specification does not support threads although there is a proposal to add one. So I imagine that till the wasm specification includes it, we will continue to have only single threaded canisters.
multi-memory
-
Top 8 Recent V8 Updates
Support for multi-memory to deal with multiple memories in Wasm.
-
WASI Support in Go
> You can do attacks that most people haven't been able to do for 20+ years.
This is a bad and roundabout way to say that vulnerabilities in WebAssembly modules may cause a corruption in their linear memory. Which is absolutely true, but those attacks still matter today (not everyone turns ASLR on) and similar defences also apply. In the future multiple memories [1] should make it much easier to guard against remaining issues. WebAssembly is a lucrative target only because it is so widespread, not because it has horrible security (you don't know what the actually horrible security looks like).
[1] https://github.com/WebAssembly/multi-memory/blob/main/propos...
-
WASI: WebAssembly System Interface
Thanks! These claims are really interesting.
- WASM has no ASLR.
So I guess if a buffer overrun lets you modify a function pointer, you could replace that function pointer with another pointer to execute different code. As you say, this is hard in native linux programs because ASLR and NX. You need a pointer to some code thats loaded in memory and you need to know where it is. In wasm, the "pointer" isn't a pointer at all. indirect_call takes an index into the jump table. Yes, this makes it easier to find other valid function pointers. But wasm also has some advantages here. Unlike in native code, you can't "call" arbitrary locations in memory. And indirect_call is also runtime typechecked. So you can't call functions with an unexpected type signature. Also (I think) the jump table itself can't be edited by the running wasm module. So there's no way to inject code into the module and run it.
I could be wrong, but I wouldn't be surprised if on balance wasm still ends up safer than native code here. I'm sure there will be more than zero wasm sandbox escapes made by abusing this, but I haven't heard of any so far.
Docs: https://developer.mozilla.org/en-US/docs/WebAssembly/Underst...
- WASM allows writing to 0x0.
You're probably right about this. To be clear, it means if pointers are set to 0 then dereferenced, the program might continue before crashing. And the memory around 0 may be overwritten by an attacker. How bad this is in practice depends on the prevelance of use-after-free bugs (common in C / C++) and what ends up near 0 in memory. In rust, these sort of software bugs seem incredibly rare. And I wouldn't be surprised if wasm compilers for C/C++ start making a memory deadzone here - if they aren't doing that already.
- wasm can easily overflow buffers
Sure, but so can native C code. And unlike native code, wasm can't overflow buffers outside of the data section. So you can't overwrite methods or modify the memory of any other loaded modules. So on net, wasm is still marginally safer than native code here. If you're worried about buffer overflows, use a safer language.
- wasm doesn't have the concept of read-only memory
Interesting! I can see this definitely being useful for system libraries like mmap. This would definitely be nice to have, and it looks like the wasm authors agree with you.
https://github.com/WebAssembly/multi-memory/issues/15
-
Accessing WebAssembly reference-typed arrays from C++
There are stray references to the concept of multiple address spaces (or 'memories') in the wasm spec at present, and I recall at one point you may have always been passing 'memory #0' to your load/store opcodes. It looks like people are still working on that as the solution.
https://github.com/WebAssembly/multi-memory
-
WebAssembly and C++
It's not segmented, so no... or rather, not yet.
The wasm spec already accommodates to some extent the notion of multiple "memories" (i.e. distinct flat heaps), although it only allows for one in practice:
https://webassembly.github.io/spec/core/syntax/modules.html#...
And there's an active proposal to allow for multiple memories:
https://github.com/WebAssembly/multi-memory/blob/main/propos...
In an environment like that, you'd need full-fledged pointers to carry both the memory index and the offset; and then you might want a non-fat "pointer to same memory" alternative for perf. Might as well call them far and near.
- WebAssembly 2.0 Working Draft
What are some alternatives?
WASI - WebAssembly System Interface
wajic - WebAssembly JavaScript Interface Creator
webcontainer-core - Dev environments. In your web app.
memory-control - A proposal to introduce finer grained control of WebAssembly memory.
onload - OpenOnload high performance user-level network stack
reference-crdts - Simple, tiny spec-compliant reference implementations of Yjs and Automerge's list types.
Uno Platform - Build Mobile, Desktop and WebAssembly apps with C# and XAML. Today. Open source and professionally supported.
uwm-masters-thesis - My thesis for my Master's in Computer Science degree from the University of Wisconsin - Milwaukee.
function-references - Proposal for Typed Function References
sdk - The Dart SDK, including the VM, dart2js, core libraries, and more.
gc - Branch of the spec repo scoped to discussion of GC integration in WebAssembly
proposals - Tracking WebAssembly proposals