On 2020-08-01 07:59, Marek Marczykowski-Górecki wrote: > On Fri, Jul 31, 2020 at 02:17:05PM -0700, Jason M wrote: >> I then looked into alternatives to prevent my complete departure from >> Qubes. Marek told me about DomB, which is now in its design stages. It >> would allow me to statically partition my machine (like having 2 dom0 VMs > > Not really 2 dom0 in a sense you would need. What you'd need is a 2 > hardware domains (dom0 by default) and that can still be only one. One > of domB proposal goals is to make it more meaningful to have hardware > domain != dom0, by eliminating dom0. > >> *GOALS* >> The final goals would be to support all Qubes features and apps. > > Yes!! > >> *STAGE 1* >> The initial goal is to get Qubes to be able to manage the virtual machines >> (start, stop, etc) using 'qvm-*' tools and *Qubes Manager*. Seamless VM >> video or audio will not be implemented in stage 1 so either a GPU will need >> to be passed through to the VM (which will also be able to provide HDMI >> audio), or access using spice or vnc. Stage 1 goals include the following: > >> - Use same template system Qubes currently uses including settings like >> *qvm-prefs*, *features*, *tags*, etc. >> - Obviously support PCI pass-through using Nvidia drivers for RTX GPU >> - Support qrexec communication from host <-> vm >> - Locking down KVM host >> - Securing the network - look into ability to enabling *sys-net* and >> *sys-firewall* > > One challenge with the last point is to have VM<->VM network connection > (like sys-net - sys-firewall) without exposing the host to the traffic. > Most (all?) of the traditional KVM setups assumes the host is responsible > for routing network traffic.
In most KVM setups that I know of, the kernel network stack is considered trusted. That’s a reasonable assumption for production servers, which have server-grade NICs and are behind enterprise routers, but not for Qubes. > One idea is to use netdev socket to connect two VMs directly, but I > worry about the performance... We could also reimplement the Xen netfront/netback protocols on top of KVM shared memory. Future versions of KVM might even have direct support for Xen paravirtualized drivers. > One thing to consider is also enabling memory deduplication in KVM > (KSM). This should nicely save memory when running multiple similar VMs, > but at the same time is risky in light of speculative execution and also > rowhammer-style attacks. Honestly, I don’t think that deduplication is worth it, especially in light of TRRespass. It also makes side-channel attacks far, *far* easier to exploit. What *might* be safe is mapping read-only data (such as dom0-provided kernels) into multiple VMs > Yes, no issue as stubdomains are not existing on KVM. This could be a nasty issue for HVMs, as without stubdomains, all emulation must be done in dom0. Google and Amazon both solved this by writing their own VMMs. At some point, KVM might be able to move the instruction emulation into userspace, which might be a significant win. (What I *really* want is a version of QubesOS based on seL4. But seL4 didn’t support 64-bit VMs last I checked, and I am not aware of any tooling for creating and destroying VMs at run-time. Most of the userspace tooling around seL4 is based on CAmkES, which requires that every component be statically known at compile-time. Furthermore, getting seL4’s hypervisor and IOMMU support verified would either require someone to fund the project, or someone who has sufficient skill with the Isabelle proof assistant to do it themselves. Without verification, the benefits of using seL4 are significantly diminished.) Sincerely, Demi -- 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 qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/a0fa62fd-941b-c450-542c-59be6c7c238c%40gmail.com.
signature.asc
Description: OpenPGP digital signature
