-----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 SxCKqletfRCseirLAqDoCynqKa3mBQ== =OwmZ -----END PGP SIGNATURE----- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/20200212001613.GR7869%40mail-itl.
