Re: A practical and compelling distributed cap platform: Sandstorm on Cap'n Proto

On 5 August 2014 10:00, Kenton Varda <[email protected]> wrote:
> Hi Thomas,
>
> On Tue, Aug 5, 2014 at 12:24 AM, Thomas Leonard <[email protected]> wrote:
>>
>> It wasn't totally clear to me from the page what it actually does.
>
>
> See also: https://github.com/sandstorm-io/sandstorm#how-it-works

Thanks, that clarifies things.

>> How
>> are the web apps sandboxed? Using VMs? Containers? Processes? Can I
>> upload any VM image, like with OpenStack or OpenNebula? If so, how is
>> this different?
>
>
> Linux containers. We use the same kernel features that Docker uses. Apps are
> packaged in a custom format, but you can build and upload arbitrary
> packages.
>
> The main difference from Docker or any of the other things you mention is
> that Sandstorm actually has a user interface appropriate for non-technical
> users, and an implementation appropriate for running single-user app
> instances. Sandstorm containers can scale to the extremely small, such that
> it not only makes sense for every user to have their own instance of an app,
> but it even makes sense for every document to be a separate instance.
>
> This is accomplished by:
> - App instances only run while they're in-use (e.g. while the user has the
> app open in their browser). The containers are lightweight enough that they
> can start and stop quickly.
> - The app code, libraries, and assets are mapped into the container
> read-only, such that the files can be shared among all containers running
> the same app. Only the /var directory is writable; it contains the
> instance-specific data. If done right, the marginal memory overhead of each
> new app instance can be kept extremely small, because all the code is in
> shared mmap'd pages. (Admittedly that doesn't quite work when the code is
> dynamically parsed/compiled at runtime, but we have some ideas involving
> checkpointing to solve that.)
>
> Sandstorm further differs from traditional IaaS/PaaS in that it implements
> unified authentication and authorization/sharing. If every document is in a
> separate sandbox, then Sandstorm can implement access control on the
> sandbox, freeing the app from having to worry about it. We can also
> implement a Powerbox UI for introducing apps to each other.
>
>> We're trying to provide a user-friendly Xen hosting system for users
>> to install web-apps on their home routers, developer boards, etc. Our
>> plan is for the VMs themselves to be tiny unikernels written in OCaml
>> (very little C except for malloc and the boot code):
>>
>>   http://nymote.org/
>>
>> Here's an example of a simple web-app I wrote to test it:
>>
>>   http://roscidus.com/blog/blog/2014/07/28/my-first-unikernel/
>>
>> I'd certainly like to get some ocaps in here, and the technologies you
>> describe sound useful.
>
>
> Is there a Nymote demo somewhere, similar to demo.sandstorm.io? I have seen
> Nymote a few times but I admit I've have trouble forming a mental model of
> what it does without being able to use it. What kind of apps are available
> on it today?

As far as I know, there are no Nymote apps currently. Work so far has
been on building the infrastructure (Xen, unikernels, a pure OCaml
TCP/IP stack, a pure OCaml TLS implementation, the Irim Git DB, etc).
These are all now available, so I expect work on Nymote itself will
begin soon.

> One thing I've wondered: How easy is it to take an existing app written in,
> say, PHP or Node.js, and run it on Nymote?

As a regular Xen host, you should be able to run any normal Linux
guest alongside the unikernels. Presumably, sandstorm could itself be
one of the guest VMs.

>> How did you fix the DoS problems we had with pipelining in E?
>>
>> (being able to use lots of resources on a server by doing bignum
>> calculations on ints, making millions of copies of strings and lists,
>> etc)
>
> Cap'n Proto does not implement mobile code, so the client is limited to
> calling the things the server exports. To create a bignum or perform ops on
> in, the server application would have to explicitly expose an interface for
> doing these things.
>
> That said, there are certainly resource exhaustion attacks possible
> currently. We have more work to do here.


-- 
Dr Thomas Leonard        http://0install.net/
GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1
GPG: DA98 25AE CAD0 8975 7CDA  BD8E 0713 3F96 CA74 D8BA