Re: [solo5] Plans to support WebAssembly as a target
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 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 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. >>
Re: [solo5] Plans to support WebAssembly as a target
(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 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
[solo5] Plans to support WebAssembly as a target
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? Thanks, Jonathan Beri.
