[prev in list] [next in list] [prev in thread] [next in thread]
List: qubes-devel
Subject: Re: [qubes-devel] Qubes + OpenXT
From: Eric Shelton <knockknock () gmail ! com>
Date: 2017-01-19 5:12:49
Message-ID: dfd69e7c-606c-4140-9fd6-3959b17dad62 () googlegroups ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Monday, January 9, 2017 at 11:02:41 AM UTC-5, Joanna Rutkowska wrote:
>
> ...
>
> Now, having the above in mind, lets consider your proposition of
> potentially
> merging with OpenXT, or to use OpenXT as a basis for Qubes OS:
>
> First, I don't think the fact they decided to use the D-Bus protocol as a
> universal solution for their inter-VM communication should be considered
> as
> disqualifying reason for us reusing their code. Instead, we should treat
> it as a
> red light for the security competence of the team that have created their
> architecture. A Big Red Light with a Roaring Fire Siren, to be more
> precise.
>
I suppose the extent to which such issues would be a liability for OpenXT
(or certain parts of it) serving as a base for Qubes depends on what is
being used, how it is incorporated into Qubes, and whether trust can be
invested in the parts that are used. For example, like Qubes, OpenXT
maintains a number of patches applied against upstream Xen. Perhaps Qubes
might use the same hypervisor, if those patches were considered auditable.
Additionally, as a downstream project, Qubes could pick and choose from
the OpenXT patches and apply additional ones, if needed.
> Indeed, OpenXT, previously known as XenClient XT, has a history of what I
> see as
> bad security architecture decisions. Besides the above-criticized choice
> of
> D-Bus as a fundamental building block for any VM-spanning services,
> another
> striking example is the adoption of GPU pass-through as their primary
> graphics
> virtualization technology.
>
> While I'm sure that the word "pass-through" brings very positive
> connotations to
> most readers ("something that doesn't require much handling from the
> hypervisor
> side"), and also looks great on powerpoint diagrams ("arrows indifferently
> crossing the hypervisor box"), in reality GPU pass-through require lots of
> complexity on the hypervisor side, which the slides often forget to
> mention.
>
> E.g. what happens when the real GPU is taken away from the VM? Are we
> going to
> give it some *emulation* for the time being to keep it happy? If so, what
> if
> there is a bug in the emulation code (there surely is, 'cause GPU's are
> complex)? What privileges would the VM obtain after exploiting the GPU
> emulation
> code?
>
> On more recent Intel GPUs the situation has presumably improved, but the
> fact XT
> has decided to chose this insecure form of graphics virtualization over
> the much
> more secure approach that we designed for Qubes OS, so many years ago, is
> another fact that makes me very uneasy about the security expertise of the
> XT
> team.
>
Although the above discussion and criticisms may have been correct for
OpenXT's predecessor, XenClient XT, my understanding is that approach was
abandoned by OpenXT. Instead, they appear to run guests under QEMU, and
make use of its emulated VGA adapter, much as done for an HVM appvm under
Qubes (ignoring Windows Tools).
These slides discuss where the project is headed with display and input
management:
http://www.slideshare.net/xen_com_mgr/xpds16-display-handler-a-client-display-framework-for-xen-brendan-kerrigan-assured-information-security-inc
As illustrated in slides 19-21 of that deck, a guest's use of a monitor is
all or nothing, apparently requiring switching from one "virtual console"
to another. However, although that sort of user interface experience is
very different from Qubes, that is not important for the idea of
incorporating OpenXT components as a base for Qubes. Instead, what is more
relevant is whether their approach for input and display for HVM domains is
something that can reasonably be plugged into the Qubes GUI framework for
running an HVM domain. If so, their stubdomain approach might be borrowed
with little modification. Qubes, even making use of OpenXT components,
could still start up appvms, start applications within them, and provide
input and display in pretty much the same way it does currently.
> (Because of this architecture decision, BTW, what XT people call "UIVM",
> is not
> the same as what we call "GUI domain", and which we plan to introduce some
> time
> after 4.0 release. In XT architecture, UIVM is a natural consequence of
> the GPU
> pass-through model, and is merely a label assigned to one-of-the-many VMs
> which
> can get full pass-through access to the GPU. In Qubes, the GUI domain is
> planed
> to be *the only one* VM granted pass-through access to the GPU, while we
> would
> continue to be using our -- I believe -- very secure GUI virtualization
> protocol
> to allow other VMs to access graphics.)
>
The UIVM is likely more than just a label. It suggests OpenXT has already
done some degree of disaggregating dom0 from the domain that manages the
display, and demonstrates an underlying use and division of domains that is
compatible with the Qubes approach.
> Last but not least, probably the most fundamental difference between XT
> and
> Qubes (and partly also responsible for some architectural differences) is
> in the
> philosophy. XT attempts to implement the classic
> multiple-isolated-(virtual)-computers-inside-one-box model (aka Multi
> Level
> Security, or MLS), which originates from the military world. Qubes, on the
> other
> hand, attempts to provide one secure desktop platform, which uses multiple
> isolated VMs to securely decompose various tasks.
>
> I've never quite got convinced by this MLS approach, to be honest. After
> all,
> what's the point of running a few monolithic Windows VMs, if each of them
> is
> still... a buggy, monolithic VM which can get compromised just as easily?
> Of
> course, the official ideology of MLS says that even if an attacker
> compromises
> one of the VMs, then they would not be able to at least leak the data to
> other,
> unclassified networks.[*] In any case, the MLS proponents believe that
> these
> systems could be useful to e.g. stop an insider from stealing gigabytes of
> confidential info and leaking them out somewhere. Looks like this might
> not have
> quite worked out for some of the organizations who are well known to
> promote
> this security model (and incidentally also XT and SELinux)... ;)
>
> Contract this to the Qubes approach, where we would like to utilize
> multiple
> domains in order to actually make the domains more difficult to attack.
> Whether
> by making them "disposable", or by splitting the tasks between more than
> one VM
> (and potentially having some of these other VMs as disposable, or easily
> recoverable).[**]
>
I'm not convinced that a Qubes built on top of or using OpenXT components
requires buying in to the MLS approach. You can use the same hypervisor
and other components - just use them differently.
What could be beneficial for Qubes is not so much building it "on top of
OpenXT" or adopting the OpenXT architecture as it is identifying software
components might be packaged up in a way that they could be effectively
shared and maintained across both projects. Stepping back and looking at
the two projects from a 30,000 foot view, there are a fair number of things
in common that might somehow be packaged up for common code across the
projects. Things such as:
- measured boot (including extending measured boot to VMs)
- improvements/fixes to upstream Xen (OpenXT is exploring disabling
unnecessary Xen features - https://openxt.atlassian.net/browse/OXT-839 -
something that I think the Qubes dev team would also like to be doing with
Xen to remove bells and whistles like nested HVM)
- patches to the Linux kernel (keeping up with new kernels)
- "modern" stubdomains (based on upstream QEMU, rather than QEMU 1.2 or so)
- PCI passthrough (their users want this feature too, including GPU
passthrough)
- solid Windows guest support (a fair number of users need/want this.
Qubes still has no solution for sound in Windows, but OpenXT does)
- a build framework (The Qubes build system is "unique." Will it be the
desired long term approach?)
All the above complains about XT focus on the architecture. And I'd argue
> that
> for a project like Qubes the proper architecture is something that should
> always
> come first. Or to stay it differently: even the best code cannot be
> "rescued" if
> it implements a bad architecture.
>
> But perhaps they could produce some good code that we could consume
> nevertheless? Well, maybe yes. Or maybe not. Somebody would need to take a
> look.
> Likely we could utilize some non-critical pieces. But surely the idea of
> using
> OpenXT as a *basis* for Qubes OS is not a good idea.
>
As I discussed above, I think the number and "criticality" of reasonably
shared components could be much greater without compromising Qubes'
security. Qubes and OpenXT have a number of similar features that might be
implemented using common code.
> I also feel obliged to protest slightly against singling out any single
> individual as a central force which keeps the project going. First, this
> makes
> disservice to many others (many of which enlisted on our
> always-lagging-behind
> Team page, but some not recognized even there) who also have contributed
> to the
> project. Sometimes under-recognized when looking at the git statistics.
>
> Consider e.g. Rafał Wojtczuk, who implemented most of the GUI
> virtualization in
> a way that it has not needed any modifications over the last 7 years...
> Yet,
> many might be tempted to overlook this when counting commits. This is also
> thanks to a reasonably good architecture of the GUI virtualization, I
> think,
> another aspect that almost never shows itself in the log.
>
Also, we shall not forget about the mysterious forces in the universe who
> -- for
> all these years -- have paid the salaries of the core team. It's quite
> likely
> Qubes would have ceased to exist long ago, if not for these magical
> fairies ;)
> In other words, Qubes should not be equated with any single person.
>
I 100% acknowledge that I am looking at which people have been active
lately; they are the ones likely to make things happen in 2017, 2018, and
beyond. I wonder where will the project go from here, and how? It was by
no means intended to diminish past efforts and contributions such as
Rafał's.
From that perspective, it has been mostly the efforts of a single
developer, however that person's work was funded or inspired, that has been
keeping Qubes going the last couple of years. Did the #2 Qubes contributor
in 2016 do even 10% as much as Marek (by whatever metric you consider
sensible: number of commits, lines of code, etc)? Somehow Marek keeps up
with the relentless rollout of new versions of Fedora and other
dependencies that inevitably break various aspects of Qubes, answers all
manners of user questions, debugs or helps debug obscure and difficult
issues arising from running a desktop OS on top of Xen, fixes things that
"should" but don't quite work in Xen, makes sure Qubes keeps up with XSAs,
and on top of that makes sure the project advances forward towards ver 4.
So, although thanks to Rafał and others Qubes came into being years ago, I
don't think it was inappropriate for me to say that "without Marek, I don't
think there would be a Qubes today" - with "today" meaning just that:
2016-2017. Marek is the one putting fingers to keyboard and both realizing
and maintaining Qubes in the present.
> Speaking of good developers, I'd like to also share an observation that
> very
> good and bright developers are often a source of troubles in security, and
> that
> we should all, both developers and non-developers (e.g. researchers), be
> very
> [wary] of that all the time.
>
> This (surely controversial) paradox might be a result of the fact that
> being
> developer -- in essence -- is about learning how to master complexity.
> Modern
> languages and frameworks allows one, and in fact even encourage, to
> implement
> ever more complex creations, almost always hiding all the complexity in
> the
> shadow. (For example: to use D-Bus for communication between
> differently-privileged domains[***])
>
> But the complexity is still there. At the end of the day, whatever
> software we
> write, it will finally get translated to the machine code and execute as
> such.
>
> But enough bashing of developers :) Without developers (or devops) Qubes
> would
> not have existed. Nor it would make sense without all the offensive
> security
> expertise that have been invested into it, especially in the early days.
> And
> this brings us back to where we started, i.e. the unique value of the
> project :)
>
I don't think any of us see Qubes as suffering from this. Also, Qubes
gives us a great tool that allows us to contain the risk or damage
resulting from imperfect software.
Back in 2009-2010 (the days of the Qubes architecture spec), it was
reasonable to conclude that Qubes would have to do a lot of things "from
scratch" - Qubes was doing things that no other open source project had
done. However, now there are others that have been, and are trying to,
solve similar problems, and implementing similar solutions. I think the
Qubes team could competently identify parts of the OpenXT project that
could become common software components across the two projects. I don't
think Qubes has to adopt the OpenXT architecture (whatever that may be
beyond the D-Bus inter-vm comm) to get the benefits of using OpenXT code.
I think there is a reasonable prospect of reducing the amount of code
unique to, and accordingly having to be maintained solely by, Qubes, and at
the same time maybe picking up some features that the Qubes team does not
have the resources to pursue on its own.
I'll also note that this is a very Qubes-centered pitch. OpenXT has things
to gain as well from doing this. For one, disaggregation of USB out of
dom0 into a USBVM is a problem that has been solved by Qubes.
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/dfd69e7c-606c-4140-9fd6-3959b17dad62%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[Attachment #5 (text/html)]
<div dir="ltr">On Monday, January 9, 2017 at 11:02:41 AM UTC-5, Joanna Rutkowska \
wrote:<blockquote class="gmail_quote" style="margin: 0;margin-left: \
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">...<br> <br>Now, having the \
above in mind, lets consider your proposition of potentially <br>merging with OpenXT, \
or to use OpenXT as a basis for Qubes OS: <br>
<br>First, I don't think the fact they decided to use the D-Bus protocol as a
<br>universal solution for their inter-VM communication should be considered as
<br>disqualifying reason for us reusing their code. Instead, we should treat it as a
<br>red light for the security competence of the team that have created their
<br>architecture. A Big Red Light with a Roaring Fire Siren, to be more precise.
<br></blockquote><div><br></div><div>I suppose the extent to which such issues would \
be a liability for OpenXT (or certain parts of it) serving as a base for Qubes \
depends on what is being used, how it is incorporated into Qubes, and whether trust \
can be invested in the parts that are used. For example, like Qubes, OpenXT \
maintains a number of patches applied against upstream Xen. Perhaps Qubes might use \
the same hypervisor, if those patches were considered auditable. Additionally, as a \
downstream project, Qubes could pick and choose from the OpenXT patches and apply \
additional ones, if needed.</div><div> </div><blockquote class="gmail_quote" \
style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: \
1ex;">Indeed, OpenXT, previously known as XenClient XT, has a history of what I see \
as <br>bad security architecture decisions. Besides the above-criticized choice of
<br>D-Bus as a fundamental building block for any VM-spanning services, another
<br>striking example is the adoption of GPU pass-through as their primary graphics
<br>virtualization technology.
<br>
<br>While I'm sure that the word "pass-through" brings very positive \
connotations to <br>most readers ("something that doesn't require much \
handling from the hypervisor <br>side"), and also looks great on powerpoint \
diagrams ("arrows indifferently <br>crossing the hypervisor box"), in \
reality GPU pass-through require lots of <br>complexity on the hypervisor side, which \
the slides often forget to mention. <br>
<br>E.g. what happens when the real GPU is taken away from the VM? Are we going to
<br>give it some *emulation* for the time being to keep it happy? If so, what if
<br>there is a bug in the emulation code (there surely is, 'cause GPU's are
<br>complex)? What privileges would the VM obtain after exploiting the GPU emulation
<br>code?
<br>
<br>On more recent Intel GPUs the situation has presumably improved, but the fact XT
<br>has decided to chose this insecure form of graphics virtualization over the much
<br>more secure approach that we designed for Qubes OS, so many years ago, is
<br>another fact that makes me very uneasy about the security expertise of the XT
<br>team.
<br></blockquote><div><br></div><div><div>Although the above discussion and \
criticisms may have been correct for OpenXT's predecessor, XenClient XT, my \
understanding is that approach was abandoned by OpenXT. Instead, they appear to run \
guests under QEMU, and make use of its emulated VGA adapter, much as done for an HVM \
appvm under Qubes (ignoring Windows Tools).</div><div><br></div><div>These slides \
discuss where the project is headed with display and input \
management:<br></div></div><div>http://www.slideshare.net/xen_com_mgr/xpds16-display-h \
andler-a-client-display-framework-for-xen-brendan-kerrigan-assured-information-security-inc<br></div><div><br></div><div>As \
illustrated in slides 19-21 of that deck, a guest's use of a monitor is all or \
nothing, apparently requiring switching from one "virtual console" to \
another. However, although that sort of user interface experience is very different \
from Qubes, that is not important for the idea of incorporating OpenXT components as \
a base for Qubes. Instead, what is more relevant is whether their approach for \
input and display for HVM domains is something that can reasonably be plugged into \
the Qubes GUI framework for running an HVM domain. If so, their stubdomain approach \
might be borrowed with little modification. Qubes, even making use of OpenXT \
components, could still start up appvms, start applications within them, and provide \
input and display in pretty much the same way it does currently.</div><div> \
</div><blockquote class="gmail_quote" style="margin: 0;margin-left: \
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">(Because of this architecture \
decision, BTW, what XT people call "UIVM", is not <br>the same as what we \
call "GUI domain", and which we plan to introduce some time <br>after 4.0 \
release. In XT architecture, UIVM is a natural consequence of the GPU \
<br>pass-through model, and is merely a label assigned to one-of-the-many VMs which \
<br>can get full pass-through access to the GPU. In Qubes, the GUI domain is planed \
<br>to be *the only one* VM granted pass-through access to the GPU, while we would \
<br>continue to be using our -- I believe -- very secure GUI virtualization protocol \
<br>to allow other VMs to access graphics.) <br></blockquote><div><br></div><div>The \
UIVM is likely more than just a label. It suggests OpenXT has already done some \
degree of disaggregating dom0 from the domain that manages the display, and \
demonstrates an underlying use and division of domains that is compatible with the \
Qubes approach.</div><div> <br></div><blockquote class="gmail_quote" style="margin: \
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Last but not \
least, probably the most fundamental difference between XT and <br>Qubes (and partly \
also responsible for some architectural differences) is in the <br>philosophy. XT \
attempts to implement the classic \
<br>multiple-isolated-(virtual)-<wbr>computers-inside-one-box model (aka Multi Level \
<br>Security, or MLS), which originates from the military world. Qubes, on the other \
<br>hand, attempts to provide one secure desktop platform, which uses multiple \
<br>isolated VMs to securely decompose various tasks. <br>
<br>I've never quite got convinced by this MLS approach, to be honest. After all,
<br>what's the point of running a few monolithic Windows VMs, if each of them is
<br>still... a buggy, monolithic VM which can get compromised just as easily? Of
<br>course, the official ideology of MLS says that even if an attacker compromises
<br>one of the VMs, then they would not be able to at least leak the data to other,
<br>unclassified networks.[*] In any case, the MLS proponents believe that these
<br>systems could be useful to e.g. stop an insider from stealing gigabytes of
<br>confidential info and leaking them out somewhere. Looks like this might not have
<br>quite worked out for some of the organizations who are well known to promote
<br>this security model (and incidentally also XT and SELinux)... ;)
<br>
<br>Contract this to the Qubes approach, where we would like to utilize multiple
<br>domains in order to actually make the domains more difficult to attack. Whether
<br>by making them "disposable", or by splitting the tasks between more \
than one VM <br>(and potentially having some of these other VMs as disposable, or \
easily <br>recoverable).[**]
<br></blockquote><div><br></div><div>I'm not convinced that a Qubes built on top \
of or using OpenXT components requires buying in to the MLS approach. You can use \
the same hypervisor and other components - just use them \
differently.</div><div><br></div><div>What could be beneficial for Qubes is not so \
much building it "on top of OpenXT" or adopting the OpenXT architecture as \
it is identifying software components might be packaged up in a way that they could \
be effectively shared and maintained across both projects. Stepping back and \
looking at the two projects from a 30,000 foot view, there are a fair number of \
things in common that might somehow be packaged up for common code across the \
projects. Things such as:</div><div>- measured boot (including extending measured \
boot to VMs)<br></div><div><div>- improvements/fixes to upstream Xen (OpenXT is \
exploring disabling unnecessary Xen features - \
https://openxt.atlassian.net/browse/OXT-839 - something that I think the Qubes dev \
team would also like to be doing with Xen to remove bells and whistles like nested \
HVM)</div><div>- patches to the Linux kernel (keeping up with new \
kernels)</div><div>- "modern" stubdomains (based on upstream QEMU, rather \
than QEMU 1.2 or so)</div><div>- PCI passthrough (their users want this feature too, \
including GPU passthrough)</div><div>- solid Windows guest support (a fair number of \
users need/want this. Qubes still has no solution for sound in Windows, but OpenXT \
does)<br></div><div>- a build framework (The Qubes build system is \
"unique." Will it be the desired long term \
approach?)</div></div><div><br></div><blockquote class="gmail_quote" style="margin: \
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">All the above \
complains about XT focus on the architecture. And I'd argue that <br>for a \
project like Qubes the proper architecture is something that should always <br>come \
first. Or to stay it differently: even the best code cannot be "rescued" if \
<br>it implements a bad architecture. <br>
<br>But perhaps they could produce some good code that we could consume
<br>nevertheless? Well, maybe yes. Or maybe not. Somebody would need to take a look.
<br>Likely we could utilize some non-critical pieces. But surely the idea of using
<br>OpenXT as a *basis* for Qubes OS is not a good idea.
<br></blockquote><div><br></div><div>As I discussed above, I think the number and \
"criticality" of reasonably shared components could be much greater without \
compromising Qubes' security. Qubes and OpenXT have a number of similar \
features that might be implemented using common code.</div><div> </div><blockquote \
class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc \
solid;padding-left: 1ex;">I also feel obliged to protest slightly against singling \
out any single <br>individual as a central force which keeps the project going. \
First, this makes <br>disservice to many others (many of which enlisted on our \
always-lagging-behind <br>Team page, but some not recognized even there) who also \
have contributed to the <br>project. Sometimes under-recognized when looking at the \
git statistics. <br>
<br>Consider e.g. Rafał Wojtczuk, who implemented most of the GUI virtualization in
<br>a way that it has not needed any modifications over the last 7 years... Yet,
<br>many might be tempted to overlook this when counting commits. This is also
<br>thanks to a reasonably good architecture of the GUI virtualization, I think,
<br>another aspect that almost never shows itself in the log.
<br></blockquote><div><br></div><blockquote class="gmail_quote" style="margin: \
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Also, we shall \
not forget about the mysterious forces in the universe who -- for <br>all these years \
-- have paid the salaries of the core team. It's quite likely <br>Qubes would \
have ceased to exist long ago, if not for these magical fairies ;) \
</blockquote><blockquote class="gmail_quote" style="margin: 0;margin-left: \
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br>In other words, Qubes \
should not be equated with any single person. \
<br></blockquote><div><br></div><div><div>I 100% acknowledge that I am looking at \
which people have been active lately; they are the ones likely to make things happen \
in 2017, 2018, and beyond. I wonder where will the project go from here, and how? \
It was by no means intended to diminish past efforts and contributions such as \
Rafał's. </div><div><br></div><div>From that perspective, it has been mostly \
the efforts of a single developer, however that person's work was funded or \
inspired, that has been keeping Qubes going the last couple of years. Did the #2 \
Qubes contributor in 2016 do even 10% as much as Marek (by whatever metric you \
consider sensible: number of commits, lines of code, etc)? Somehow Marek keeps up \
with the relentless rollout of new versions of Fedora and other dependencies that \
inevitably break various aspects of Qubes, answers all manners of user questions, \
debugs or helps debug obscure and difficult issues arising from running a desktop OS \
on top of Xen, fixes things that "should" but don't quite work in Xen, \
makes sure Qubes keeps up with XSAs, and on top of that makes sure the project \
advances forward towards ver 4. So, although thanks to Rafał and others Qubes came \
into being years ago, I don't think it was inappropriate for me to say that \
"without Marek, I don't think there would be a Qubes today" - with \
"today" meaning just that: 2016-2017. Marek is the one putting fingers to \
keyboard and both realizing and maintaining Qubes in the present.</div></div><div> \
<br></div><blockquote class="gmail_quote" style="margin: 0;margin-left: \
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Speaking of good developers, \
I'd like to also share an observation that very <br>good and bright developers \
are often a source of troubles in security, and that <br>we should all, both \
developers and non-developers (e.g. researchers), be very <br>[wary] of that all the \
time. <br>
<br>This (surely controversial) paradox might be a result of the fact that being
<br>developer -- in essence -- is about learning how to master complexity. Modern
<br>languages and frameworks allows one, and in fact even encourage, to implement
<br>ever more complex creations, almost always hiding all the complexity in the
<br>shadow. (For example: to use D-Bus for communication between
<br>differently-privileged domains[***])
<br>
<br>But the complexity is still there. At the end of the day, whatever software we
<br>write, it will finally get translated to the machine code and execute as such.
<br>
<br>But enough bashing of developers :) Without developers (or devops) Qubes would
<br>not have existed. Nor it would make sense without all the offensive security
<br>expertise that have been invested into it, especially in the early days. And
<br>this brings us back to where we started, i.e. the unique value of the project :)
<br></blockquote><div><br></div><div>I don't think any of us see Qubes as \
suffering from this. Also, Qubes gives us a great tool that allows us to contain \
the risk or damage resulting from imperfect software. </div><div><br></div><div>Back \
in 2009-2010 (the days of the Qubes architecture spec), it was reasonable to conclude \
that Qubes would have to do a lot of things "from scratch" - Qubes was \
doing things that no other open source project had done. However, now there are \
others that have been, and are trying to, solve similar problems, and implementing \
similar solutions. I think the Qubes team could competently identify parts of the \
OpenXT project that could become common software components across the two projects. \
I don't think Qubes has to adopt the OpenXT architecture (whatever that may be \
beyond the D-Bus inter-vm comm) to get the benefits of using OpenXT code. I think \
there is a reasonable prospect of reducing the amount of code unique to, and \
accordingly having to be maintained solely by, Qubes, and at the same time maybe \
picking up some features that the Qubes team does not have the resources to pursue on \
its own.</div><div><br></div><div>I'll also note that this is a very \
Qubes-centered pitch. OpenXT has things to gain as well from doing this. For one, \
disaggregation of USB out of dom0 into a USBVM is a problem that has been solved by \
Qubes.</div><div><br></div><div>Best,</div><div>Eric</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/dfd69e7c-606c-4140-9fd6-3959b17dad \
62%40googlegroups.com?utm_medium=email&utm_source=footer">https://groups.google.com/d/ \
msgid/qubes-devel/dfd69e7c-606c-4140-9fd6-3959b17dad62%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