WebAssembly has the power to level the playing field for games distribution. Why do we need Steam, which opposes a 30% tax to developers and only works on PC, whereas the browser is open and platform-agnostic?
Interesting, I am curious how were you able to achieve this, Baldurs Gate 2 is a closed source game, I guess its possible to have written a lifter for LLVM WASM?
This is using GemRB, which itself is a reimplementation of Bioware's Infinity Engine. GemRB is ported to WASM, and it loads the game demo data in the filesystem. Pure magic, if you ask me :)
Or Firefox Desktop, they don't pass the required headers to enable Firefox's Spectre mitigations in order to use SharedArrayBuffer. I can't tell if Chrome will require it too, because they already do iframes in separate processes.
I believe the general plan is to require the headers in all browsers, for SharedArrayBuffer, including Chrome. (But currently, they work regardless there.)
That is not the case although Web Assembly advocates sell it otherwise, thankfully security researchers are now finally caring to have a deeper look into their claims.
Sandboxing is only part of the solution, it doesn't protect all possible attack vectors.
For example, bounds checking is only enforced on the boundaries of the linear memory segment, not inside it.
So if you have a Web Assembly module, originally written in C, where all memory allocations get mapped into a single linear memory segment, there is no protection against possible corruption of neighbouring data structures.
With this in mind you can indirectly attack a module by providing data to the public APIs that would eventually change the expected results, for example returning an admin token for a security module, instead of a regular one that the API was expected to return for then given user id.
21 comments
[ 2.8 ms ] story [ 47.3 ms ] threadThis is truly the future of gaming.
https://youtu.be/UQiUP2Hd60Y
But that seems to be an insane effort.
[0] https://github.com/gemrb/gemrb
[0] https://store.steampowered.com/app/257350/Baldurs_Gate_II_En...
https://itch.io/t/1028526/cross-origin-policies-for-webassem... itch.io enabled them globally in the past, but it broke some things.
https://personal-1094.web.app/gemrb.html
https://www.usenix.org/conference/usenixsecurity20/presentat...
I thought the whole point of WASM was that it was sandboxed by the browser. Is that not the case, or is it just poorly done?
Sandboxing is only part of the solution, it doesn't protect all possible attack vectors.
For example, bounds checking is only enforced on the boundaries of the linear memory segment, not inside it.
So if you have a Web Assembly module, originally written in C, where all memory allocations get mapped into a single linear memory segment, there is no protection against possible corruption of neighbouring data structures.
With this in mind you can indirectly attack a module by providing data to the public APIs that would eventually change the expected results, for example returning an admin token for a security module, instead of a regular one that the API was expected to return for then given user id.