4 ms·

My VM is Lighter (and Safer) than your Container (2017)

FastEatSlow 4y ago
This is pretty neat, how well does this compare to how services such as cloudlare workes currently operate?
gnabgib 4y ago
This is only just posted 18 days ago[0] with 309pts, 105 comments [0]: https://news.ycombinator.com/item?id=32764501 https://news.ycombinator.com/item?id=32764501
imiric 4y ago
I skimmed the paper, but the premise makes sense in some scenarios. I don't think unikernels have quite taken off as they were hyped a few years ago, but in general, micro VMs are quite more usable nowadays. I recently gave Firecracker a try, via the friendlier interface of Ignite[1], and was pleasantly surprised how quick it was to start a VM from a Docker image, and how little resources it used. The UX is pretty much on par with Docker, yet gives much more flexibility, control, and of course, security. I wish there was a competitor to QubesOS that uses KVM, and is a bit friendlier and more polished. Is there such a distro? [1]: https://github.com/weaveworks/ignite https://github.com/weaveworks/ignite
wyager 4y ago
What do you trust more: kernel-mode virtio drivers or the limited subset of kernel-mode /dev drivers and user-mode APIs exposed to containers? It's not at all clear to me that a VM is safer than a (well-designed) containerization system, such as freebsd jails.
- wmf 4y ago
  I love containers but virtio definitely has a lower surface area.
  - wyager 4y ago
    Than what? In most of my containers I only expose extremely basic devices like `/dev/random`, which are extremely unlikely to have vulnerabilities. Virtio drivers are very complicated and very privileged.
    - naikrovek 4y ago
      it's not a matter of what you expose. VMs are simply more isolated than containers. VM isolation happens in hardware -- the processor, and is supported by the processor; container isolation happens in the OS kernel, and the hardware can not offer any features to containers that it can offer to virtual machines.
      - wyager 4y ago
        > VMs are simply more isolated than containers. This doesn't mean anything - it is just a cliché. > VM isolation happens in hardware -- the processor, and is supported by the processor This is also meaningless, or at least doesn't mean what you think it does. Container isolation also happens "in hardware", in the sense that both are facilitated by e.g. features in the MMU. VMs may or may not take advantage of some additional hardware features (e.g. hardware-assisted HBA virtualization), but most of these do not necessarily provide any security benefit, and in many cases expose additional attack surface area that would not be accessible from inside a container. The only difference from a security standpoint is which APIs are exposed to processes running inside the guest environment. Both VMs (with practical peripherals) and containers have access to scary stuff running in kernel mode. It's mostly a disjoint set of stuff, and it's not clear to me which set is actually preferable from a security standpoint.
        naikrovek 4y ago
        I don't know what you're so angry about, but it's dripping off of the page. no one is angry here but you. why? CPUs do not have hardware containerization support. they DO have hardware virtualization support. containers know they are containers, necessarily. virtual machines do not know they are virtual machines unless the platform they see as physical hardware tells them they are a virtual machine, which is not a requirement for virtualization. CPUs which support virtualization extensions isolate virtual machines from each other at a hardware level. the CPU, at a hardware level, knows about each virtual machine, where its memory is, and what each virtual machine is doing. for containers, that's all the kernel, and only the kernel. the containers talk through the host kernel to the outside world, and they all share the same OS kernel. that is arguably the opposite of isolation. a virtual machine host (in reality a sibling virtual machine with special privileges) can run operating system A, and there can be x number of sibling VMs, all running different operating systems; Linux, MacOS, Windows, FreeBSD, BeOS, whatever. they are separated all the way down to the CPU and RAM. the managing virtual machine cannot see inside its sibling virtual machines normally, and would require escalation to CPU ring -2 (or is it -3?) to become a superuser in the eyes of the hypervisor. I don't know how to be more clear. if you are still in disagreement, maybe you are unaware of type-1 vs. type-2 hypervisors, and/or you're talking about one while I am talking about another. others have given up on this conversation and I now join them.

This is pretty neat, how well does this compare to how services such as cloudlare workes currently operate?

This is only just posted 18 days ago[0] with 309pts, 105 comments [0]: https://news.ycombinator.com/item?id=32764501 https://news.ycombinator.com/item?id=32764501

imiric 4y ago

I skimmed the paper, but the premise makes sense in some scenarios. I don't think unikernels have quite taken off as they were hyped a few years ago, but in general, micro VMs are quite more usable nowadays. I recently gave Firecracker a try, via the friendlier interface of Ignite[1], and was pleasantly surprised how quick it was to start a VM from a Docker image, and how little resources it used. The UX is pretty much on par with Docker, yet gives much more flexibility, control, and of course, security. I wish there was a competitor to QubesOS that uses KVM, and is a bit friendlier and more polished. Is there such a distro? [1]: https://github.com/weaveworks/ignite https://github.com/weaveworks/ignite

wyager 4y ago

What do you trust more: kernel-mode virtio drivers or the limited subset of kernel-mode /dev drivers and user-mode APIs exposed to containers? It's not at all clear to me that a VM is safer than a (well-designed) containerization system, such as freebsd jails.

wmf 4y ago
I love containers but virtio definitely has a lower surface area.
- wyager 4y ago
  Than what? In most of my containers I only expose extremely basic devices like `/dev/random`, which are extremely unlikely to have vulnerabilities. Virtio drivers are very complicated and very privileged.
  - naikrovek 4y ago
    it's not a matter of what you expose. VMs are simply more isolated than containers. VM isolation happens in hardware -- the processor, and is supported by the processor; container isolation happens in the OS kernel, and the hardware can not offer any features to containers that it can offer to virtual machines.
    - wyager 4y ago
      > VMs are simply more isolated than containers. This doesn't mean anything - it is just a cliché. > VM isolation happens in hardware -- the processor, and is supported by the processor This is also meaningless, or at least doesn't mean what you think it does. Container isolation also happens "in hardware", in the sense that both are facilitated by e.g. features in the MMU. VMs may or may not take advantage of some additional hardware features (e.g. hardware-assisted HBA virtualization), but most of these do not necessarily provide any security benefit, and in many cases expose additional attack surface area that would not be accessible from inside a container. The only difference from a security standpoint is which APIs are exposed to processes running inside the guest environment. Both VMs (with practical peripherals) and containers have access to scary stuff running in kernel mode. It's mostly a disjoint set of stuff, and it's not clear to me which set is actually preferable from a security standpoint.
      - naikrovek 4y ago
        I don't know what you're so angry about, but it's dripping off of the page. no one is angry here but you. why? CPUs do not have hardware containerization support. they DO have hardware virtualization support. containers know they are containers, necessarily. virtual machines do not know they are virtual machines unless the platform they see as physical hardware tells them they are a virtual machine, which is not a requirement for virtualization. CPUs which support virtualization extensions isolate virtual machines from each other at a hardware level. the CPU, at a hardware level, knows about each virtual machine, where its memory is, and what each virtual machine is doing. for containers, that's all the kernel, and only the kernel. the containers talk through the host kernel to the outside world, and they all share the same OS kernel. that is arguably the opposite of isolation. a virtual machine host (in reality a sibling virtual machine with special privileges) can run operating system A, and there can be x number of sibling VMs, all running different operating systems; Linux, MacOS, Windows, FreeBSD, BeOS, whatever. they are separated all the way down to the CPU and RAM. the managing virtual machine cannot see inside its sibling virtual machines normally, and would require escalation to CPU ring -2 (or is it -3?) to become a superuser in the eyes of the hypervisor. I don't know how to be more clear. if you are still in disagreement, maybe you are unaware of type-1 vs. type-2 hypervisors, and/or you're talking about one while I am talking about another. others have given up on this conversation and I now join them.