-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Tue, Feb 11, 2020 at 05:35:36PM -0500, Demi M. Obenour wrote:
> The Qubes project has criticized
> Xen’s approach to security in the past
> (https://lists.xen.org/archives/html/xen-devel/2015-11/msg00601.html).
> Has the Xen project made improvements since then?
Yes and no. Many things have improved over time, for example Kconfig
give ability to disable compile-time unwanted parts and most if not all
new features are added with such option (and while in "experimental"
state - are disabled by default). Another thing that have improved is
testing - there is now quite elaborate test infrastructure, including
both full system tests, but also unit tests of critical components (like
instruction emulation) and fuzzy tests of some of them.
Many developers also takes time to cleanup the existing code, remove
dead features etc. This part is going to take a long time, also because
it isn't the top priority, but is moving forward. One thing that is on
the horizon, is ability to turn off PV support completely - the place
with the most legacy code.
But some things remained the same - for example default Xen build still
tries to download "random" tarballs from the internet (admittedly this
is limited to old mini-os stubdomain build only). Also, not adding
safety checks for non-trivial assumptions (or adding only as ASSERT that
affects debug build only) is something that still happens in new code
too.
As for "why Xen" question - because that's still the best _existing_
thing that can is a reasonable compromise between security features
and hardware support. Where "security features" I mean:
1.1. not forcing you to trust all-powerful host system with complex device
emulation (qemu or similar) - aka running qemu sufficiently sandboxed
1.2. not forcing you to trust all-powerful host system with network
routing, all kind of inter-vm communication - aka driver domains
1.3. running isolation-enforcing hypervisor as a clearly separate
component, separate from drivers for all kind of random devices you
plug into your system - aka type1 hypervisor
And where "hardware support" I mean:
2.1. being able to run on modern systems and allow to run modern
software within VMs
2.2. being able to run on client machines, where things like power
management, suspend etc are de facto hard requirement
2.3. being able to use existing main stream OS drivers for "random
hardware" (we're not in a business of writing/porting own drivers...)
The part about hardware support rules out basically everything besides
type2 hypervisors hosted on Linux (or Windows, but that's another story)
and few type1 hypervisors (Xen, maybe ESXi but not sure about power
management). From the type2 hypervisors the closest we can get is KVM
and indeed there are some improvements over the last few years - like
ability to sandbox qemu using various Linux mechanisms (especially
seccomp-bpf). But still, there is no support for routing network traffic
without involvement of the host system (even if you do PCI passthrough
of all the network adapters into a VM, you still need to route it back
to the host to be able to distribute it to other VMs).
So, in short - KVM is getting closer to what would be acceptable
solution, but still quite not there. Anyway, if someone would like to
help with actual development, we can consider KVM as a _secondary_
supported hypervisor. And in fact some parts (like vchan) for KVM
already exists.
Some random thoughts on the subject:
"just about everyone except the embedded folks have abandoned Xen" -
well, the surge of patches and messages in general from Amazon people on
xen-devel mailing list in the last year clearly says otherwise. People
from Suse, Intel, BitDefender and many more are also very active.
Some would ask, what about _formally verified_ seL4? It is excellent on
point 1.3 and good at points 1.1 and 1.2. And fails miserably on all the
hardware support part. It can't even run 64-bit VMs on x86.
"You don't need to use qemu on KVM, there are alternative device models"
- - kind of true if we consider Linux VMs only. And this would be actually
preferable solution if we'd go that way. But if you want to run also
other OSes (Windows?), then in practice you need qemu. And using
significantly more complex/vulnerable device model for less trusted VMs
doesn't sound very appealing.
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-BEGIN PGP SIGNATURE-
iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAl5DQ80ACgkQ24/THMrX
1yz5zQf/W81e+DBW5UD+i8Zc+4mQ74l5q7RXIAXbDh8mavAqqx/B+3a1Z3Wyz2zi
ulCNm7rqXtuNmgYTx0U9pKYENN+mEiKm+oik/ni07h4QLj4RVZyu3pvz6E+ubIs2
o801e3jWebYa26F79dLNIGn25D6mDvIZIL+RSM8KE8zbexDdXuc7z2l4uA8KAl10
MJRd6TsXS2NQ85JCyAyZbwnatRRwlNYiONnc3fpjA4L5gEowCF2PBMO3rtlDKYUU
NKdFyWU+8ADnNX9661T4b7TO2g/W6CF4iMwJndyyuIwFvLbNOlL6oJxCn21d8ENt
