Sure. I've been working on KVM for 7 years, and I only recall two really serious vulnerabilities:
1) one bug that let you escape into the guest kernel from unprivileged guest userspace (CVE-2010-0306 and CVE-2010-0419). Even that one required relatively special circumstances, so that in practice the only exploitable user program was the X server, but this is not a bug you want to have in your hypervisor.
2) one bug that let you escape the host kernel from the guest kernel (CVE-2014-0049). Also very hard to exploit, but doable.
The "memory sinkhole" problem does not apply to virtualization.
> > If security were just about less code, OpenBSD-specific stuff like pledge or SOCK_DNS wouldn't have any place.
>
> pledge is much smaller than SELinux
It's still >0 lines of code. (BTW, comparing pledge and SELinux is apples and oranges).
> If your mail server is broken because of bugs in your mail server, or bugs in your hypervisor, then there are two codebases with an attack-surface not one.
If you place mail+web server on the same machine without a hypervisor, things can certainly be less secure than if you place multiple services on the same machine separated by the hypervisor. In the first case, breaking the web server results in a direct attack to the mail server. In the second case, after breaking the web server you still need to go against the smaller attack surface of the hypervisor.
> Thinking about keeping mail server bugs in the mail server is a red herring; it just isn't important to users, so this isn't how you should evaluate "security."
It's about keeping web server bugs in the web server, and not have them infect the mail server.
> I only recall two really serious vulnerabilities.
Having a discriminating memory doesn't help you build programs that have no bugs. It only helps you feel better about the bugs in the programs you create. Meanwhile, real users believe DoS are serious vulnerabilities.
> If you place mail+web server on the same machine without a hypervisor, things can certainly be less secure than if you place multiple services on the same machine separated by the hypervisor.
No. It isn't certain. The hypervisor is just more code. Why should anyone believe more code is going to produce less bugs?
> The "memory sinkhole" problem does not apply to virtualization.
Why do you think so?
Users believed they could "place multiple services on the same machine separated by the hypervisor" would be more secure, and then it turned out they couldn't. If only they had used a simpler system they would have had actual security. This is evident.
> It's about keeping web server bugs in the web server, and not have them infect the mail server.
Wrong. A bug in the Linux PCI code affects web servers. A bug in ext4 affects a mail server. Don't you get it? Big programs have bugs.
Yes, talking about hardware virt only.
> Give numbers.
Sure. I've been working on KVM for 7 years, and I only recall two really serious vulnerabilities:
1) one bug that let you escape into the guest kernel from unprivileged guest userspace (CVE-2010-0306 and CVE-2010-0419). Even that one required relatively special circumstances, so that in practice the only exploitable user program was the X server, but this is not a bug you want to have in your hypervisor.
2) one bug that let you escape the host kernel from the guest kernel (CVE-2014-0049). Also very hard to exploit, but doable.
The "memory sinkhole" problem does not apply to virtualization.
> > If security were just about less code, OpenBSD-specific stuff like pledge or SOCK_DNS wouldn't have any place. > > pledge is much smaller than SELinux
It's still >0 lines of code. (BTW, comparing pledge and SELinux is apples and oranges).
> If your mail server is broken because of bugs in your mail server, or bugs in your hypervisor, then there are two codebases with an attack-surface not one.
If you place mail+web server on the same machine without a hypervisor, things can certainly be less secure than if you place multiple services on the same machine separated by the hypervisor. In the first case, breaking the web server results in a direct attack to the mail server. In the second case, after breaking the web server you still need to go against the smaller attack surface of the hypervisor.
> Thinking about keeping mail server bugs in the mail server is a red herring; it just isn't important to users, so this isn't how you should evaluate "security."
It's about keeping web server bugs in the web server, and not have them infect the mail server.