I don't know anything about ZeroVM, but performance would only come into play when/if it crosses boundaries, and even then, only if the APIs at the boundary are slow. User space on Linux provides a lot of features to make crossing boundaries not slow. Zero copy write with sendfile(), efficient async I/O with epoll(), etc. are tools to allow user space applications to cross that boundary efficiently.

That said, user space file systems are slower than in-kernel file systems; at least, according to the data I've seen. But, I suspect ZeroVM will be used in ways that aren't quite the pathological case of a user-space filesystem under benchmark load.

As for access, Linux has a nice capabilities system to allow user space to access privileged resources as a non-privileged user and without being in ring 0 (if privileged access is even needed, which it likely won't be in the cases where this will be used, I would think). Again, this would still be through the public APIs, and not by acting like the kernel and hitting the hardware directly.

I don't think, or get the impression, that this would be used for full-system virtualization. It seems to be more targeted toward an AWS Lambda sort of usage pattern; a micro-VM that spins up to serve one API request, or to act as a long-running tiny daemon to do some housekeeping task. It looks like a fancy fork(), to me, rather than a competitor to Docker or LXC (and especially not KVM or Xen, which can run a whole Linux kernel in the VM).