Actually... I don't think the Qubes goals and the OpenXT goals are all that dissimilar. As already stated, OpenXT used to be XenClient XT, and the open source community basically inherited a bunch of code from Citrix that really needed a LOT of work. The use of DBus for example is something everyone wants to get rid of (and has been brought up a lot). I would not "blindly" accept any code from anyone (as previously mentioned), but there are a lot of things that OpenXT does that could be done better in Xen, the QEMU stubdomain for example. Joanna's summary of the graphics layer is out-of-date as well (the link from Xen summit that Brendan presented is a good reference), and to address the above comment, OpenXT's main use case are Windows guest VMs, so there is a fair amount of work to support Windows really well.
Seems to me there is probably a things both teams to leverage / learn from. - Rian On Saturday, January 7, 2017 at 11:58:39 AM UTC-7, Eric Shelton wrote: > > A couple of recent events prompted me to look more into the OpenXT project: > - The recent announcements about Qubes' funding and shift in development > priorities. It is great to hear that Qubes will remain an open source > effort. However, there has consistently only been a small handful of > developers active in Qubes -- mainly those being paid by ITL (without > Marek, I don't think there would be a Qubes today). With their priorities > being set by commercial clients, it seems less certain what Qubes will > focus on, and on what schedule they will get there. I suppose there just > aren't all that many non-ITL open source contributors with the needed Linux > internals and Xen internals expertise looking to chip in, and maybe this > situation will not change anytime soon. > - It came to my attention that OpenXT has implemented Linux-based > stubdomains using upstream QEMU - an issue long neglected by upstream Xen. > Qubes is working on this, and maybe it will be a 4.0 feature. > > A couple of quick summaries of the OpenXT effort: > > http://www.slideshare.net/xen_com_mgr/the-openxt-project-in-2016-christopher-clark-bae-systems > http://www.slideshare.net/xen_com_mgr/tricca-xen-summit2014 > > OpenXT is also the open source core of a very Qubes-like OS: SecureView: > > https://www.fbcinc.com/e/cdse/presentations/day2/10-SecureView_Overview_-_Capt_Alex_Gwin_-_FINAL_-_Day_2.pdf > > I believe I am reasonably familiar with the Qubes project, and to me there > seems to be a significant amount of overlap in the missions and solutions > of Qubes and OpenXT - especially where it counts: the "security research" > and virtual desktop integration areas. This also translates into a lot of > duplicated effort across these two projects. OpenXT has their own > TPM/AEM/measured launch, PV-USB (implemented long ago, and with Windows > support), stub domains (they have long used Linux-based stubdomains, and > will be moving up to QEMU 2.6 soon), netvm, and a UIVM that has been > separated from dom0. I'm not saying everything is a one-to-one match with > the Qubes architecture, but I can say that Qubes has been, and continues > to, spend its precious and limited resources implementing and updating > features that are already implemented and being updated in OpenXT. Also, > OpenXT is way ahead of Qubes on Windows guest support (which I suspect is > important for the Qubes commercialization path). There are also many ideas > implemented or being worked on in Qubes that strike me as positive > improvements for OpenXT: usbvm, seamless desktop, template domains, etc. > > Perhaps it is worth considering (or reconsidering?) bringing the efforts > of these two projects together. OpenXT might offer a reasonable base > architecture for Qubes, and allow the Qubes team to not spread itself so > thin (Marek and company are tackling problems from the BIOS on up, and that > presents a lots of software that is changing (changes in KDE broke the > window decoration, Wayland in F25 will surely bring new headaches) and > constantly is pulling the Qubes developers away from their core mission. > In some ways, isn't this what the HAL effort (which unfortunately does not > seen to have achieved much) was about - abstracting Qubes away from the > base hypervisor architecture? > > The only comment I have seen from the Qubes developers about OpenXT is > criticism of their use of dbus in their interdomain communication > architecture (https://twitter.com/rootkovska/status/505024924097196032). > I imagine the Qubes team can find a reasonable way around that. I > understand there is going to be a significant "not invented here" > resistance to this idea, but keep in mind that there are at least as many > smart and security conscious developers working on OpenXT, too. > > Perhaps another issue is that the developers working on OpenXT, for the > most part, work for US defense industry contractors. SecureView appears to > have ties with the NSA and the US Air Force. On the other hand, I will > point out that these same parties are also contributors to upstream Xen and > Linux - although among many others (and hypothetically, many more "sets of > eyes" - however well that concept actually works in practice). Plus, > somehow people long ago rationalized Tor having arisen from US Naval > Research Laboratory and receiving ongoing funding from the US government. > For what it is worth, Qubes could be a viable competitor for SecureView > (especially if built on OpenXT), if you want to pursue that avenue for > commercial funding. > > I love Qubes, and it would be great if it had loads of resources to > continue to do everything from the bottom to the top and remain the > somewhat independent effort it has been for the last couple of years. But > that is not the case, is it? If building Qubes on top of OpenXT allows > Qubes developers to focus on the unique aspects of Qubes instead of fixing > up things being broken by other projects, that would allow Qubes developer > hours to be focused on developing the aspects that are unique to Qubes, > demonstrate the value of Qubes, and perhaps establish a more sustainable > cycle for Qubes (user interest, commercial interest, developer interest, > etc.) that better ensures the project can continue. Plus, I suspect both > projects have a lot to gain from each other. Frankly, otherwise I fear > that the Qubes project will, despite the team's best intentions and > efforts, fizzle out over the next few years. > > Best, > Eric > > -- 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 post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/1896dc3c-ac2d-485a-8cf4-e4ce5f14122b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
