It looks like hardened *nix process. It has no access to anything it's not permitted to access. And it has no notion of network, time or machine it's running on, although it can communicate with other instances (even on remote machines) via ipc. It can be suspended, resumed, relocated and so on without it ever noticing.
Thank you. When you instantiate a zerovm instance you give it the associated code as well? And which IPC method can it use? Is zerovm the library you use, is there such a thing as a separate zerovm instance, or is it just the way we are used to talking about virtualization?
You get nothing but /dev/stdin, /dev/stdout, and /dev/stderr by default. You can optionally make other resources (network, files) available, through a similar api.
Comments
It looks like hardened *nix process. It has no access to anything it's not permitted to access. And it has no notion of network, time or machine it's running on, although it can communicate with other instances (even on remote machines) via ipc. It can be suspended, resumed, relocated and so on without it ever noticing.
Thank you. When you instantiate a zerovm instance you give it the associated code as well? And which IPC method can it use? Is zerovm the library you use, is there such a thing as a separate zerovm instance, or is it just the way we are used to talking about virtualization?
You give it an x86 (or ARM) binary to execute. NaCL is also working on an LLVM version, that would get compiled to the specific machine at runtime.
IPC is super limited: https://github.com/zerovm/zerovm/blob/master/doc/api.txt
You get nothing but /dev/stdin, /dev/stdout, and /dev/stderr by default. You can optionally make other resources (network, files) available, through a similar api.