It would be better to use CBOR, or at least ELF. The former, especially, is not too far from WASM's format (both favor compact integer representation), and bears semblance to JSON which bears semblance to JS which bears semblance to WASM. It only makes too much sense. But WASM didn't take that direction, so we don't benefit from a highly extensible, simple and elegant format with widespread support.
I hope WASM fixes this soon.
It seems that designers want to keep it simple, but it is inevitable to bring concepts like sections and symbol tables in when it comes to linking: https://github.com/WebAssembly/tool-conventions/blob/master/...
I think a lot of this is limited by existing OS mechanisms. I've been digging into seL4 to create a platform for WebAssembly code, but moving internationally eats up all your time. :(
> We might consider adjusting the precision of timers or removing them altogether as an attempt cripple the program’s ability to read timing side-channels.
> Unfortunately we now know that this mitigation is not comprehensive. Previous research  has shown three problems with timer mitigations: (1) certain techniques to reduce timer resolution are vulnerable to resolution recovery, (2) timers are more pervasive than previously thought and (3) a high resolution timer can be constructed from concurrent shared memory. The Amplification Lemma from Section 2.4 is the final nail in this coffin, as it shows (4) gadgets themselves can be amplified to increase the timing differences to arbitrary levels.
As someone working with Web Audio, I wonder if it's even possible to tell if a program "legitimately" needs milli/microseconds timing precision? Typically it'd be running on its own worker/audiolet(?) thread, but I imagine it could be exploited for some nefarious purpose.
Edit: I realized the talk is about WASM on the server, but, who knows, maybe in the future it could also involve audio that needs high-precision timers.
Anyway, thank you for the notes/slides about WebAssembly on the server, fascinating stuff with a bright future!
Ruby, Python, JVM languages (Kotlin/Clojure/Java/Scala etc), Node platform languages (TypeScript, ClojureScript, ES5 etc)... Go comes to mind as the only exception, delivering native binaries, but it supports cross compilation really well.
Go also doesn't cross compile with cgo that elegantly. Having the platform run the output of C compilers means that you can remove that from your runtime assumptions as well.
(As a sidenote, POWER has supported either endianness for a while, and ~everyone runs Linux in little-endian mode.)
Given that the point of cgo more or less is to enable calling into C code, don't you still need to do a lot to make that work in WASM? Like cross-compile all your C dependencies to WASM, then use cgo to interface between the go things and the c things within the WASM runtime?
Pretty interesting ideas and I'm interested to see how it plays out, but tbh I think I'm too old school for all this newfangled stuff and would just use qemu.
Wasm does provide that property for C++ & Rust. I'm unsure how important that is in the server space.
it really feels like future of lambda\cloud functions
The idea was that the cost of using WASM would be entirely offset by the speedup of removing the cost of hardware memory protection. We could do that if everything ran in one big VM because the VM would enforce the memory protection.
Unfortunately, now we can't rely on a VM for memory protection anymore. We have to assume that any code running in the same address space can access any memory in the same address space.
So we need the hardware memory protection after all. You can say goodbye to your WASM-only future.
V8 at least have given up on the concept of trying to protect memory within the same address space.
It doesn't seem likely. The chipmakers will fix the vulnerabilities that break isolation between processes and between user-kernel, but the within-process issues will probably stick around.
This is an interesting way to put it. I would have said "applies to pretty much every CPU manufactured in the last decades." Your statement would make sense if speculation in hardware was some niche thing, but I think you would be hard-pressed to find an invulnerable CPU that is used in situations where people care about both performance and security.
That's great for the mill, but isn't relevant to the world outside of mill computing.
WASM already has this problem, what with 5 or 6 different incompatible runtimes already in existence.
It’s not literally “run anywhere” it’s “for all intents and purposes run anywhere”.
(Emphasis on optional)
People have tried to create high level language CPUs but often failed in terms of performance. An overview can be found here: https://en.wikipedia.org/wiki/High-level_language_computer_a...
Also WASM isn't really ideal for interpretation, this could make implementing the CPU harder (however I have no clue about implementing CPUs, so this is just a guess).
What would be the advantage? Performance? Probably not much after JIT compiling WASM to native machine instructions. If there is an actual problem there, I guess it would be better to just add new native instructions that support WASM semantics. The JIT can then use these instructions if available.
Right now WASM can't do much without a runtime, so I think a WASM-only CPU is probably infeasible for some time.
As the OP said: this is reinventing the JVM, just worse. Including making all the mistakes again.
(At least for the server, that is. I see a great future for WebAssembly on client systems, where the JVM can be considered a failure.)
And the long forgotten SWF, P-Code, M-Code, UNCOL, ANDF, Xerox bytecode.
What does this mean, removing the OS from the equation?