Xen Project Blog

> will there be a future where all I/O paths in AWS EC2 access PCI passthrough

That's a business, not technology question. Possible today if I/O is priced for exclusivity to one workload, same as a dedicated server. Most AWS customers want shared workload (low) pricing.

> Debugability

In general, hypervisors provide more debug options than a single OS, since the host OS can introspect into the guest OS, even to record/replay guest OS execution, e.g. http://www.slideshare.net/mobile/xen_com_mgr/xentt-deterministic-systems-analysis-in-xen

Real-time hypervisor scheduling is an ongoing research area, e.g. here is an automotive use case, http://blog.xen.org/index.php/2013/11/27/rt-xen-real-time-virtualization-in-xen/ & http://www.cse.wustl.edu/~lu/papers/emsoft11.pdf

> for very large sites with thousands of instances

Yes, containers work well for Google who doesn't need to worry about isolation. Most businesses are not Google nor are they running a real-time workload. With containers, SE Linux provides a necessary layer of defense, http://opensource.com/business/14/7/docker-security-selinux & http://blog.docker.com/2014/07/new-dockercon-video-docker-security-renamed-from-docker-and-selinux/

Paravirtualization bad, hardware virtualization good, is not an accurate view. You actually want a hybrid model to get the best performance. That's why KVM developers have put so much effort into the paravirtualized virtio drivers, for example. Xen has put lots of work into taking advantage of new hardware virtualization technology where it makes sense and continuing paravirtualization where it makes sense. See the two links below for great details.

http://blog.xen.org/index.php/2012/10/23/the-paravirtualization-spectrum-part-1-the-ends-of-the-spectrum/

http://blog.xen.org/index.php/2012/10/31/the-paravirtualization-spectrum-part-2-from-poles-to-a-spectrum/

Here is a pretty big one from 2012 that was discovered by Rafal Wojtczuk: http://www.vupen.com/blog/20120904.Advanced_Exploitation_of_Xen_Sysret_VM_Escape_CVE-2012-0217.php

It didn't get a huge press release and media coverage but it was a pretty big deal. Probably because there weren't any 0day exploits floating around at the time so this flew under the radar of the mainstream.

http://blog.xen.org/index.php/2012/06/13/the-intel-sysret-privilege-escalation/

http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0217

http://invisiblethingslab.com/itl/About.html

You are correct in that you need performance parity for two items to be comparable.

You are incorrect in saying that you take an order of magnitude performance hit when Virtualization, especially for CPU bound tasks [1].

In terms of disk you are slightly more correct, you can lose substantial performance, however it's still not an order of magnitude.

[1] http://blog.xen.org/index.php/2011/11/29/baremetal-vs-xen-vs-kvm-redux/ (A series of benchmarks showing a disparity of ~1% off bare metal on CPU bound tasks.)

Per http://blog.xen.org/index.php/2012/06/13/the-intel-sysret-privilege-escalation/

"Linux actually fixed the bug in 2006, with CVE-2006-0744. [ http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0744 ] But the description says “Linux kernel before 2.6.16.5 does not properly handle uncanonical return addresses on Intel EM64T CPUs…”, which makes it sound like something Linux-specific. It’s therefore not surprising that it attracted little notice from other operating systems."

This one?

http://blog.xen.org/index.php/2012/06/13/the-intel-sysret-privilege-escalation/

http://www.vupen.com/blog/20120904.Advanced_Exploitation_of_Xen_Sysret_VM_Escape_CVE-2012-0217.php

Exploits are developed to break VMs, just like everything else, and are promptly patched once revealed. Apart from general intrusion detection tools, I think you would be hard pressed to find anything to guard against them.

Maybe run a VM inside another VM ;)