5 ms·

> 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

by 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.
- wyager 4y ago
  Why do you think I'm angry? I'm just pointing out that you are saying things that don't carry semantic content without prevaricating about it. Apologies if that comes off as hostile - I don't really have time to write this in a gentler way. > CPUs do not have hardware containerization support. they DO have hardware virtualization support. I already explained why this is wrong with specific examples. > containers know they are containers, necessarily User-mode processes need not know they are containerized, and this has nothing to do with security. > virtual machines do not know they are virtual machines unless... This is in practice not true, even with fully simulated hardware. Look up "VM detection". > the CPU, at a hardware level, knows about each virtual machine, where its memory is, and what each virtual machine is doing That is not how virtualization works at all. Once again, not trying to be hostile, just don't have time to say this gently. This is the kind of thing people say when they haven't actually written code against virtualization extensions. The CPU does not "know" anything about what VMs are running - that is not an abstraction that is reified at the hardware level. > and they all share the same OS kernel With access to kernel resources gated via a specific set of APIs - same as with a VM. Again, the question is just which set of APIs you trust. > they are separated all the way down to the CPU and RAM. Another meaningless cliche that suffices for a basic mental model of VMs, but insufficient for security reasoning > the managing virtual machine cannot see inside its sibling virtual machines normally, and would require escalation Precisely the same statement applies for containers. > I don't know how to be more clear. There is no need - it is already perfectly clear that you are simply using an insufficiently precise approximative model of how VMs work.
  - deleted 4y ago
    [deleted]

by wyager 4y ago

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.

wyager 4y ago
Why do you think I'm angry? I'm just pointing out that you are saying things that don't carry semantic content without prevaricating about it. Apologies if that comes off as hostile - I don't really have time to write this in a gentler way. > CPUs do not have hardware containerization support. they DO have hardware virtualization support. I already explained why this is wrong with specific examples. > containers know they are containers, necessarily User-mode processes need not know they are containerized, and this has nothing to do with security. > virtual machines do not know they are virtual machines unless... This is in practice not true, even with fully simulated hardware. Look up "VM detection". > the CPU, at a hardware level, knows about each virtual machine, where its memory is, and what each virtual machine is doing That is not how virtualization works at all. Once again, not trying to be hostile, just don't have time to say this gently. This is the kind of thing people say when they haven't actually written code against virtualization extensions. The CPU does not "know" anything about what VMs are running - that is not an abstraction that is reified at the hardware level. > and they all share the same OS kernel With access to kernel resources gated via a specific set of APIs - same as with a VM. Again, the question is just which set of APIs you trust. > they are separated all the way down to the CPU and RAM. Another meaningless cliche that suffices for a basic mental model of VMs, but insufficient for security reasoning > the managing virtual machine cannot see inside its sibling virtual machines normally, and would require escalation Precisely the same statement applies for containers. > I don't know how to be more clear. There is no need - it is already perfectly clear that you are simply using an insufficiently precise approximative model of how VMs work.
- deleted 4y ago
  [deleted]