[prev in list] [next in list] [prev in thread] [next in thread]
List: qubes-devel
Subject: [qubes-devel] Re: Qubes + OpenXT
From: rianquinn () gmail ! com
Date: 2017-03-09 16:40:01
Message-ID: 1896dc3c-ac2d-485a-8cf4-e4ce5f14122b () googlegroups ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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 qubes-devel+unsubscribe@googlegroups.com. To post to this group, \
send email to qubes-devel@googlegroups.com. 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.
[Attachment #5 (text/html)]
<div dir="ltr">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.<div><br></div><div>Seems to me there is probably a things both teams to \
leverage / learn from. </div><div><br></div><div>- Rian<br><br>On Saturday, January \
7, 2017 at 11:58:39 AM UTC-7, Eric Shelton wrote:<blockquote class="gmail_quote" \
style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: \
1ex;"><div dir="ltr"><div>A couple of recent events prompted me to look more into the \
OpenXT project:</div><div>- 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.</div><div>- 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.</div><div><br></div><div>A \
couple of quick summaries of the OpenXT effort:</div><div><a \
href="http://www.slideshare.net/xen_com_mgr/the-openxt-project-in-2016-christopher-clark-bae-systems" \
target="_blank" rel="nofollow" \
onmousedown="this.href='http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.slideshare \
.net%2Fxen_com_mgr%2Fthe-openxt-project-in-2016-christopher-clark-bae-systems\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGYmA6TIXsQYjpkVlpgT4UVQZq1zg';return \
true;" onclick="this.href='http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.slidesh \
are.net%2Fxen_com_mgr%2Fthe-openxt-project-in-2016-christopher-clark-bae-systems\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGYmA6TIXsQYjpkVlpgT4UVQZq1zg';return \
true;">http://www.slideshare.net/xen_<wbr>com_mgr/the-openxt-project-in-<wbr>2016-christopher-clark-bae-<wbr>systems</a></div><div><a \
href="http://www.slideshare.net/xen_com_mgr/tricca-xen-summit2014" target="_blank" \
rel="nofollow" onmousedown="this.href='http://www.google.com/url?q\x3dhttp%3A%2F%2 \
Fwww.slideshare.net%2Fxen_com_mgr%2Ftricca-xen-summit2014\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHRBtlvXzYIQBkn77xZ7wbE5s-bww';return \
true;" onclick="this.href='http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.slidesh \
are.net%2Fxen_com_mgr%2Ftricca-xen-summit2014\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHRBtlvXzYIQBkn77xZ7wbE5s-bww';return \
true;">http://www.slideshare.net/xen_<wbr>com_mgr/tricca-xen-summit2014</a><br></div><div><br></div><div>OpenXT \
is also the open source core of a very Qubes-like OS: SecureView:</div><div><a \
href="https://www.fbcinc.com/e/cdse/presentations/day2/10-SecureView_Overview_-_Capt_Alex_Gwin_-_FINAL_-_Day_2.pdf" \
target="_blank" rel="nofollow" \
onmousedown="this.href='https://www.google.com/url?q\x3dhttps%3A%2F%2Fwww.fbcinc.c \
om%2Fe%2Fcdse%2Fpresentations%2Fday2%2F10-SecureView_Overview_-_Capt_Alex_Gwin_-_FINAL \
_-_Day_2.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNExUBvWkwQX4tcSFKxlVp72tY1Uhw';return \
true;" onclick="this.href='https://www.google.com/url?q\x3dhttps%3A%2F%2Fwww.fbcin \
c.com%2Fe%2Fcdse%2Fpresentations%2Fday2%2F10-SecureView_Overview_-_Capt_Alex_Gwin_-_FI \
NAL_-_Day_2.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNExUBvWkwQX4tcSFKxlVp72tY1Uhw';return \
true;">https://www.fbcinc.com/e/cdse/<wbr>presentations/day2/10-<wbr>SecureView_Overview_-_Capt_<wbr>Alex_Gwin_-_FINAL_-_Day_2.pdf</a><br></div><div><br></div><div>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.</div><div><br></div><div>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?</div><div><br></div><div>The only comment I have seen from the Qubes \
developers about OpenXT is criticism of their use of dbus in their interdomain \
communication architecture (<a \
href="https://twitter.com/rootkovska/status/505024924097196032" target="_blank" \
rel="nofollow" onmousedown="this.href='https://www.google.com/url?q\x3dhttps%3A%2F \
%2Ftwitter.com%2Frootkovska%2Fstatus%2F505024924097196032\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFnP-dAw3-rPyRfb_ql1TRjMSu6rg';return \
true;" onclick="this.href='https://www.google.com/url?q\x3dhttps%3A%2F%2Ftwitter.c \
om%2Frootkovska%2Fstatus%2F505024924097196032\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFnP-dAw3-rPyRfb_ql1TRjMSu6rg';return \
true;">https://twitter.com/<wbr>rootkovska/status/<wbr>505024924097196032</a>). 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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Best,</div><div>Eric</div><div><br></div></div></blockquote></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups \
"qubes-devel" group.<br /> To unsubscribe from this group and stop \
receiving emails from it, send an email to <a \
href="mailto:qubes-devel+unsubscribe@googlegroups.com">qubes-devel+unsubscribe@googlegroups.com</a>.<br \
/> To post to this group, send email to <a \
href="mailto:qubes-devel@googlegroups.com">qubes-devel@googlegroups.com</a>.<br /> To \
view this discussion on the web visit <a \
href="https://groups.google.com/d/msgid/qubes-devel/1896dc3c-ac2d-485a-8cf4-e4ce5f1412 \
2b%40googlegroups.com?utm_medium=email&utm_source=footer">https://groups.google.com/d/ \
msgid/qubes-devel/1896dc3c-ac2d-485a-8cf4-e4ce5f14122b%40googlegroups.com</a>.<br /> \
For more options, visit <a \
href="https://groups.google.com/d/optout">https://groups.google.com/d/optout</a>.<br \
/>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic