Re: [solo5] Plans to support WebAssembly as a target

[Jonathan Beri]

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 
> & Cloudflare
>  are
> using WebAssembly on their Serverless compute platforms and multiple
> companies in the Blockchain space are using WebAssembly for
>  their
>  VMs
> 
> ,
>
> >  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
>  is that it
> had the foresight to allow for non-web embedding
> .
>
> > 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
> 
> 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 
> from Mozilla growing in popularity. See also Wasmtime
>  from the same team, which is
> an example of a non-web runtime. Besides wasmjit and wasmtime, see alo
> WAVM , wasmer.io & wac
> . If you're interested in the roadmap of
> WebAssembly, check out the latest talk 
> from Lin Clark.
>
> ###
>
> I've been interested in Unikernels for quite some time and recently became
> interested in WebAssembly (I run a local Meetup
> .) 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
>> >  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 

Re: [solo5] Plans to support WebAssembly as a target

[Jonathan Beri]

(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  &
Cloudflare 
are using WebAssembly on their Serverless compute platforms and multiple
companies in the Blockchain space are using WebAssembly for
 their
 VMs

,

>  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
 is that it
had the foresight to allow for non-web embedding
.

> 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

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 
from Mozilla growing in popularity. See also Wasmtime
 from the same team, which is an
example of a non-web runtime. Besides wasmjit and wasmtime, see alo WAVM
, wasmer.io & wac
. If you're interested in the roadmap of
WebAssembly, check out the latest talk  from
Lin Clark.

###

I've been interested in Unikernels for quite some time and recently became
interested in WebAssembly (I run a local Meetup
.) 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
> >  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] 

Re: [solo5] Plans to support WebAssembly as a target

[Martin Lucina]

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
>  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

[solo5] Plans to support WebAssembly as a target

[Jonathan Beri]

I enjoyed the recent presentation given at Fosdem 2019
 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.