<torhex-pasmul[m]>
what's the future of process-isolated units like sandstorm grains vs VM isolation? seeing sentiment against the former lately https://news.ycombinator.com/item?id=31760151
<isd>
There's no intrinsic reason that process isolation should be less safe than VM isolation. I would even say in principle the opposite should be true, since it's a bit easier to fuss with the syscall API to make it easy to get right & minimize attack surface than it is to fuss with the ISA in the same way (fwiw, the same argument goes up the stack to language-level isolation). But, docker has given containers a bad reputation because it hasn't
<isd>
really done that -- it tries to expose something that looks like pretty normal linux, and LPE vulnerabilities are as much of a concern there as they are elsewhere more or less. Sandstorm has a much better track record, mainly because we expose a lot less; even just banning /proc and userns alone dodges a huge number of LPEs.
<Corbin>
I respect the commenter's experience here, but there are fundamental barriers to making VMs exactly as cheap as native processes, which ruins the "cheaper and cheaper" claim, so containers are *always* going to be scheduled in packed configurations.
<Corbin>
(Generally, when a VM is fast, it's because the underlying processor is cheating somehow, and that cheating leads to security issues.)
<isd>
The main intrinsic advantage of moving isolation down the stack is compatibility; if you do isolation with VMs, you can run basically any existing software. With process isolation, you're limited to userspace software that uses the right syscall API. Language level isolation you're now restricted to a particular language, etc.
<isd>
In practice, today, it's sometimes also nice to have an extra layer of isolation (regardless of what's on top of it) just for defense in depth reasons. But people seem to have this intuition that hardware isolation is somehow easier to get right, since we don't hear about rampant problems with hardware zero-days. But that mostly reflects the effort hardware manufacturers put into correctness, not the intrinsic difficulty of the problem. Verifying
<isd>
software is probably easier, we just don't do it because the cost of having to ship a hotfix isn't that high usually.