Xen Project Blog

I believe it's this one: https://blog.xenproject.org/2012/06/13/the-intel-sysret-privilege-esca…

it would seem that there are many bug-free software pieces out there. I don't think that you can consider CPUs to be bug-free. Just to pick one, Intel got SYSRET wrong: https://blog.xenproject.org/2012/06/13/the-intel-sysret-privilege-esca…

In the past, Xen has has vulnerabilities based on things different between Intel and AMD processors, or even between different processors from the same company. It seems likely that the fleet is all running the same version of the hypervisor, but the bug only matters on 10% of their hardware. Here's a previous Xen vulnerability based on Intel implementing the SYSRET instruction (originally introduced by AMD, along with SYSCALL; Intel's version of this was SYSENTER and SYSEXIT, with different semantics about kernel stacks and things) in a slightly different way from how AMD implemented it. Both Intel's docs and AMD's docs were accurate for their own processors, but if you only read AMD's docs, you'd implement syscalls in a way that was vulnerable on Intel. https://blog.xenproject.org/2012/06/13/the-intel-sysret-privilege-esca…

Most people agree HVM is the way to go on EC2: http://www.brendangregg.com/blog/2014-05-07/what-color-is-your-xen.htm… Forcing an HVM guest to use only PV drivers sounds like PVH, which is coming in Xen 4.4: https://blog.xenproject.org/2014/01/31/linux-3-14-and-pvh/

Yea it took a while. I often joke that it took two weeks to get things working, and four years to make it maintainable. In reality, the first version did take two weeks, but maintainability grew with completeness and correctness. It also took several years to get people to stop telling me I've reinvented FUSE (which I did, but not with rump kernels ;). If you're interested, I recently touched on the early history and original motivation in this blog post: https://blog.xenproject.org/2015/08/06/on-rump-kernels-and-the-rumprun… I am absolutely certain that we'd not be having this discussion if kernel driver development had not been the original motivation. That's the buy-in for the upstream OS. See the community link at rumpkernel.org if you want more non-false information. One of the problems with "related work" is that you're trying to find some difference to your own work to justify the publication of your paper, and all that without fully understanding the related work. So you tend to make goal-driven assumptions, and hence "related work" generally tends to be more wrong than right. The exception is really well-known work, because mis-assumptions about it won't get through the PC. But then again, telling everyone what they already know is not that useful, is it? At least for myself, writing "related work" was always the hardest bit. btw, my papers are somewhat obsolete, the dissertation is still mostly accurate, even if the use case descriptions are…