On 01/22/2018 09:13 PM, Kelly Dean wrote:
Andrew David Wong writes:
Joanna Rutkowska has just published a new article titled "Qubes Air:
Generalizing the Qubes Architecture." The article is available both on
Joanna's blog:
https://blog.invisiblethings.org/2018/01/22/qubes-air.html
And on the Qubes website:
https://www.qubes-os.org/news/2018/01/22/qubes-air/
Qubes Air still has a master admin qube as a single point of failure. Qubes Air
also makes the attacker's job easier, if he's trying to traverse from one VM to
another within a slave zone in a system with heterogeneous VMMs, because he now
has another VMM to choose from, with different vulnerabilities. He can either
exploit the slave's VMM to gain control of the slave zone (including his target
VM), or exploit the master zone's VMM to gain control of the entire system
(including the slave's VMM). In contrast, a Qubes 4.0 system has only one VMM,
so the attacker doesn't get a choice.
Qubes Air also doesn't really make deployment easier. If a user needs Qubes,
that means he needs more security than a conventional OS gives. So, even in the
easiest case (Qubes in a trusted cloud), his client device still at least needs
an IOMMU-isolatable network device. Without that, the entire system is
compromisable via the netvm, via merely an exploit of the network driver or
stack, just like a conventional OS, so why would he bother running Qubes in the
first place? But if his client device does have that feature, then the most
practical OS to run on it is Qubes, so he's already going to have Qubes
deployed before bothering with the cloud.
So then, what good is Qubes Air? Apparently, managing a cluster computer. But
that's just an additional capability, after the user has already deployed and
secured his Qubes system in the first place. Contrary to the news article,
Qubes Air doesn't solve problems of initial deployment or single point of
failure.
That was also how I understood the article, with my initial response here:
https://twitter.com/ttaskett/status/955540266479489024
I know that getting mired in the month-by-month compatibility issues is
a whole lot of No Fun, and that Qubes was meant to abstract-out hardware
details to some extent (use a whole OS -- pick one -- as a video or NIC
driver). But at some point the hardware will make or break us, and the
hardware we got now is Wintel; even Linux is an afterthought when you're
not looking at server components.
Even worse, Intel has quite illegally squeezed AMD out of the market,
leaving Qubes laptop buyers little choice but to wrestle with Intel
Skylake headaches. If AMD had more revenue available circa 2011, the
possible mobile APU choices later on could have offered a nice respite
for the Qubes community. (Intel still tries to avoid paying its EU
fines, and its CEO recently dumped all the stock he was legally
allowed....but I digress...)
Qubes' role appears to be taming unruly PC hardware, transforming it
into almost a different architecture through clever use of some of its
less common features. The Wintel hardware fights back, however, with
newer models (e.g. Skylake and later) refusing to work without trying
many new kernel iterations, etc. What Windows users feel as road bumps
are much more jarring to us.
But remember Microsoft isn't hardware agnostic. They have published
parameters for hardware design since the mid-1990s at least, and much of
what they write and/or certify is the result of close relationships with
hardware brands whose every product quirk is customized for Windows use.
MS has even reacted to the rough spots in their ecosystem by producing
their own PC systems.
There is one other consumer-friendly personal computer platform, Apple.
Are they hardware agnostic? :)
The next logical step seems to be in the description of open hardware
designs that will more faithfully serve Qubes' goal of strong and usable
endpoint security. It can be as simple as a list showing what qualities
a CPU, memory controller or keyboard can and cannot have, and the
minimum manifest of component types... to lay down the important
parameters that some hardware project (perhaps interested in the BOOM
processor, for example) might decide "we can do that".
In the meantime, our hardware compatibility situation isn't so terrible,
even with what the mere compatibility overlap that Xen's passthrough and
Linux drivers afford. Looked at another way, a Qubes user typically has
more models to choose from than any Mac user can claim. The dilemma is
whether we should keep finding them, or lay groundwork for building them.
-
PS - This isn't to imply that Qubes Air isn't worth pursuing. It reminds
me of a financialized BOINC: distributed computing and verification. But
currently I don't see how it can solve the user's local trust and
compatibility concerns, which serve as a foundation for all the rest.
Proponents in the age of the "Linux desktop" (circa 2004) used to claim
that Linux was a natural alternative to Windows despite hardware issues,
because apps were moving to the web... saying that if all you need is a
browser, then hardware = solved. It sure didn't turn out how they imagined.
--
Chris Laprise, [email protected]
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886
--
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/48ed3021-925d-dde2-60ea-372a0a655dd4%40posteo.net.
For more options, visit https://groups.google.com/d/optout.
