cap-std VS bsnes-plus-wasm

I believe you mean capability based, like cap-std.

There might be another reason to prefer async-std right now: the Bytecode Alliance is working on a version of std with support for capability-based security (called cap-std: https://github.com/bytecodealliance/cap-std ), and their async version is based on async-std (called cap-async-std: https://github.com/bytecodealliance/cap-std/tree/main/cap-async-std ). Given the clout that the Bytecode Alliance has, async-std might end up carving a niche out in the Wasm domain.

Would love to see something like this implemented around creating a Process in cap-std ( https://github.com/bytecodealliance/cap-std/issues/190 )

I think it's not discussed enough how things like language features shape how library APIs are formed. People usually seem to only consider the question "how would I use this feature?" and not "how would the standard library look like with this feature?", which is surprising given how much builtin libraries affect the pleasantness of a language.

One of the things I'm excited to see is the cap-std project for Rust [0] given what Pony [1] has demonstrated is possible with capabilities. I'm also hoping that languages like Koka [2] and OCaml [3] will demonstrate interesting use cases for algebraic effects.

[0] https://github.com/bytecodealliance/cap-std

[1] https://www.ponylang.io/discover

[2] https://koka-lang.github.io

[3] https://github.com/ocaml-multicore/effects-examples

I'm not sure you could hack the control flow when running bytecode on the JVM, but I strongly doubt that. (The JVM is "high-level" as pointed out previously and doesn't execute ASM like code. So there is no of the attack surface you have to care on the ASM level).

And capabilities are anyway something that belongs into the OS — and than programs need to be written accordingly. The whole point of the capability-security model is that you can't add it after the fact. That's why UNIX isn't, and never will be, a capability secure OS.

But "sanboxing" some process running on a VM is completely independent of that!

WASM won't get you anything beyond a "simple sanbox" ootb. Exactly the same as you have in the other major VM runtimes.

If you want capability-secure Rust, there is much more to that. You have to change a lot of code, and use an alternative std. lib¹. Of course you can't than use any code (or OS functionality) when it isn't also capability-secure. Otherwise the model breaks.

To be capability-secure you have actually to rewrite the world…

¹ https://github.com/bytecodealliance/cap-std

The type system could definitely help. There's all sorts of things we can do. One really cool project is https://github.com/bytecodealliance/cap-std

On the topic of unsafe being used to describe raw file descriptors, on one hand, there is a sense in which file descriptors are pointers, into another memory. They can leak, dangle, alias, or be forged, in exactly the same way. On the other, there is an open issue about this.

I've developed quite a few SNES-related things for fun, mostly using Go and C++, with some 65816 ASM sprinkled in.

https://github.com/alttpo/alttpo - A Link To The Past Online. Lets multiple players see and interact with one another in the same game world and synchronize their progress through the game. Exclusive to a customized fork of the bsnes emulator which provides a scripting language and PPU-integrated drawing routines to render remote player sprites. In retrospect, I consider this a dead-end architecture; redesigned in o2 project (see below).

https://github.com/alttpo/o2 - Second version of alttpo (see above) but this time targeted at SNES hardware console support (via SD2SNES flash cart USB feature) and does not require a customized emulator nor a scripting language. Trade-off here is a loss of the visual aspect (cannot see remote player sprites) due to tight hardware limitations in the amount of VRAM and limited SNES CPU cycles available. Work is in progress to gain back the remote sprite rendering as an optional add-on via the bsnes-plus WASM module support (see below). This project includes a 65816 machine code emitter library (pure Go) with support for named labels of branch targets. There is also a bare-bones headless SNES emulator library (pure Go) included for unit tests to verify the generated 65816 ASM and ROM patching mechanism.

https://github.com/alttpo/bsnes-plus - A fork of bsnes-plus in development that invokes WebAssembly modules when certain general SNES events occur, e.g. `on_nmi`, `on_power`, `on_reset`, `on_frame_present`. WASM code has access to a draw-list API for drawing into the various PPU layers, e.g. extra sprites, text (with PCF font support), basic shapes. WASM code can also receive arbitrary binary messages from external applications, e.g. to update remote player positions or exchange custom sprite graphics.

Hm not really but I do update my repo on github.com. It's all work in progress stuff being designed as I go.

https://github.com/alttpo/bsnes-plus/tree/wasm/bsnes/wasm