I think for stuff like your Rails app, you'd want to wait until there is support lower level in your stack.
But imagine that you're writing a commenting system, and want to sanitise stuff received from a user. Sanitising data is error prone, so you isolate the code in a new zerovm. If someone finds a way to exploit anything in your sanitising code, they might be able to write broken sanitised HTML out, but they won't be able to e.g. send queries to your database, or write to your disk, because the zerovm simply doesn't have permission.
And imagine the web server spawning a new zerovm for every request, that only has permission to talk to the inbound network connection and pass messages between that and a Rails zerovm for that request. If there's an exploit in the HTTP parser, that vm could be exploited, but it'd die at the end of the request, and would have no permissions to talk to the database server or write to disk.
And imagine the Rails zerovm similarly being split into pieces: Request handling might be done in one; authentication might be done in one.
The lower the startup costs, the more you can afford to chop the app into pieces and the more you can leverage that to benefit in terms of security (by reducing the privileges of each individual component) and scalability (by allowing distribution of the VMs across CPUs and across servers)
How would ZeroVM instances talk to any server with persistent storage (e.g. a key/value store) in a deterministic way? get('top_stories') will change over time.
Comments
So... how do I use this with my Rails app, and to what end?
It looks like interesting technology, but I need a more concrete example.
I think for stuff like your Rails app, you'd want to wait until there is support lower level in your stack.
But imagine that you're writing a commenting system, and want to sanitise stuff received from a user. Sanitising data is error prone, so you isolate the code in a new zerovm. If someone finds a way to exploit anything in your sanitising code, they might be able to write broken sanitised HTML out, but they won't be able to e.g. send queries to your database, or write to your disk, because the zerovm simply doesn't have permission.
And imagine the web server spawning a new zerovm for every request, that only has permission to talk to the inbound network connection and pass messages between that and a Rails zerovm for that request. If there's an exploit in the HTTP parser, that vm could be exploited, but it'd die at the end of the request, and would have no permissions to talk to the database server or write to disk.
And imagine the Rails zerovm similarly being split into pieces: Request handling might be done in one; authentication might be done in one.
The lower the startup costs, the more you can afford to chop the app into pieces and the more you can leverage that to benefit in terms of security (by reducing the privileges of each individual component) and scalability (by allowing distribution of the VMs across CPUs and across servers)
How would ZeroVM instances talk to any server with persistent storage (e.g. a key/value store) in a deterministic way? get('top_stories') will change over time.