(joined the list) > Run as a component on a server with something like wasmjit, not in a browser.
Sweet! That's what I inferred. There's several folks working on this from different angles. For example, Fastly <https://wasm.fastlylabs.com/docs> & Cloudflare <https://blog.cloudflare.com/webassembly-on-cloudflare-workers/> are using WebAssembly on their Serverless compute platforms and multiple companies in the Blockchain space are using WebAssembly for <https://github.com/ewasm/design> their <https://medium.com/dfinity/why-webassembly-f21967076e4> VMs <https://medium.com/nearprotocol/why-doesnt-near-just-replicate-ethereum-serenity-design-3e2cfa2f960c> , > It should be relatively easy to use something like an Emscripten-based cross toolchain to produce Solo5 WebAssembly "binaries" (whatever they are). Generally correct, you need a toolchain/generator like Emscripten (there are others) and a WASM "runtime" like wasmjit (there are others.) One nice thing about the specification <https://webassembly.github.io/spec/core/bikeshed/index.html> is that it had the foresight to allow for non-web embedding <https://webassembly.org/docs/non-web/>. > Either keep the "no more executable pages" rule, which implies an AOT compilation step at/around deployment time (from wasm -> native code). The spec also doesn't require <https://webassembly.github.io/spec/core/bikeshed/index.html#design-goals%E2%91%A0> JIT. In fact, many of the companies I mentioned above only support AOT for similar reasons. > I'd be interested in some resources on how the transition from "writable" to "executable" memory is managed internally by the JIT. Happy to share what I know! Many of the projects rely on AOT code generators, with Cranelift <https://github.com/CraneStation/cranelift/> from Mozilla growing in popularity. See also Wasmtime <https://github.com/CraneStation/wasmtime> from the same team, which is an example of a non-web runtime. Besides wasmjit and wasmtime, see alo WAVM <https://github.com/WAVM/WAVM>, wasmer.io & wac <https://github.com/kanaka/wac>. If you're interested in the roadmap of WebAssembly, check out the latest talk <https://youtu.be/rZB9Er8aq4s> from Lin Clark. ### I've been interested in Unikernels for quite some time and recently became interested in WebAssembly (I run a local Meetup <https://www.meetup.com/wasmsf>.) I think the two could go very well together and would be happy to help in any way I can. Cheers. On Mon, Feb 18, 2019 at 2:37 AM Martin Lucina <[email protected]> wrote: > Hi Jonathan, > > (meta: You're not subscribed to the list, so your message got moderated.) > > On Sunday, 17.02.2019 at 10:07, Jonathan Beri wrote: > > I enjoyed the recent presentation given at Fosdem 2019 > > <https://fosdem.org/2019/schedule/event/solo5_unikernels/> given by > Martin > > Lucina & Ricardo Koller. At the end, Martin mentioned an idea to support > > WebAssembly as a target. How developed is the idea and has any progress > > been made in that direction? > > At this stage it's just an idea. I ran out of time towards the end of the > talk, so, to elaborate a bit on this: > > - This is about using WebAssembly as a way to get arch-independence for > Solo5-based unikernels. I.e. run as a component on a server with > something like wasmjit, not in a browser. > > - I've not looked into WebAssembly in detail at all. From my possibly > naive understanding, it should be relatively easy to use something like > an Emscripten-based cross toolchain to produce Solo5 WebAssembly > "binaries" (whatever they are). > > - The Solo5 design mandates that you get no more executable pages after > loading the unikernel binary. This precludes the use of a JIT. While > others have asked [1] to relax this, I'm very wary of doing so as it > significantly reduces "security posture" and generally goes against the > design goal of keeping the system "static". Having said that, it looks > like the "hack" described in that issue will have to go in in the short > term. > > Possible solutions to this: > > 1. Either keep the "no more executable pages" rule, which implies an AOT > compilation step at/around deployment time (from wasm -> native code). > > 2. Or, figure out a minimal, as-safe-as-possible interface at the Solo5 > layer which allows a JIT to function while *enforcing* W^X on the various > targets. I'm not sure this is possible, as it would imply e.g. in the > 'spt' case allowing at least mprotect() in the seccomp filter which is a > fairly wide attack surface. > > If you know more about how JITs work, I'd be interested in some resources > on how the transition from "writable" to "executable" memory is managed > internally by the JIT. > > - Then there's the question of what the resulting architecture > (tender/bindings) would look like, and what the interfaces to the > "outside world" are in a wasm scenario and so on. However, figuring out > the previous point is probably the biggest hurdle. > > [1] https://github.com/Solo5/solo5/issues/321 > > Hope this helps, > > Martin >
