A new AOT WebAssembly compiler called Lucet ( https://www.fastly.com/blog/announcing-lucet-fastly-native-webassembly-compiler-runtime) was just announced from Fastly that might be worth looking into.
On Mon, Feb 18, 2019, 12:42 PM Jonathan Beri <jmb...@gmail.com> wrote: > (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 <mar...@lucina.net> 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 >> >
