[prev in list] [next in list] [prev in thread] [next in thread]
List: qubes-devel
Subject: [qubes-devel] Re: Qubes + OpenXT
From: hpwhite () gmail ! com
Date: 2017-03-09 17:22:00
Message-ID: 998f55d2-f757-4df1-968c-8b1f5c419196 () googlegroups ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
I just found this thread while googling for some stuff and figured I would
chime in. I have been involved with OpenXT since it was open sourced by
Citrix, but I am not a developer (I did forward this thread on to some of
the OpenXT developers, so they may chime in as well).
I do not want to comment on what is better or worse in OpenXT or Qubes,
that is for people much smarter than me to argue, but I would like to say
that OpenXT and Qubes are BOTH client-side virtualization systems based on
Xen. Yes, they have different use cases (MLS vs. a secure single user
experience), but it sure seems like there should be a lot of commonality,
experience and brainpower that could be leveraged between the two projects.
I think it is safe to say that neither project has infinite resources for
development, so doesn't it make sense to pool the finite resources we have?
I am not saying that Qubes should be based on OpenXT or anything like that,
but if there is one feature, capability or module that can be shared why
not?
Again the smarter people would need to work the details, but I am sure the
OpenXT community would welcome constructive input, collaboration and
contribution from the the Qubes community, and it seems visa versa as well.
Phil
On Saturday, January 7, 2017 at 1:58:39 PM UTC-5, 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/998f55d2-f757-4df1-968c-8b1f5c419196%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[Attachment #5 (text/html)]
<div dir="ltr">I just found this thread while googling for some stuff and figured I \
would chime in. I have been involved with OpenXT since it was open sourced by Citrix, \
but I am not a developer (I did forward this thread on to some of the OpenXT \
developers, so they may chime in as well). <br><br>I do not want to comment on what \
is better or worse in OpenXT or Qubes, that is for people much smarter than me to \
argue, but I would like to say that OpenXT and Qubes are BOTH client-side \
virtualization systems based on Xen. Yes, they have different use cases (MLS vs. a \
secure single user experience), but it sure seems like there should be a lot of \
commonality, experience and brainpower that could be leveraged between the two \
projects. I think it is safe to say that neither project has infinite resources for \
development, so doesn't it make sense to pool the finite resources we \
have?<br><br>I am not saying that Qubes should be based on OpenXT or anything like \
that, but if there is one feature, capability or module that can be shared why \
not?<br><br>Again the smarter people would need to work the details, but I am sure \
the OpenXT community would welcome constructive input, collaboration and contribution \
from the the Qubes community, and it seems visa versa as well.<br><br>Phil<br><br>On \
Saturday, January 7, 2017 at 1:58:39 PM UTC-5, 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>
<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/998f55d2-f757-4df1-968c-8b1f5c4191 \
96%40googlegroups.com?utm_medium=email&utm_source=footer">https://groups.google.com/d/ \
msgid/qubes-devel/998f55d2-f757-4df1-968c-8b1f5c419196%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