Linux-libre in dom0

[Duncan Guthrie]

Dear Qubes Users,
I have been using Qubes OS for a couple of days now. I own a Lenovo
Thinkpad X200 and everything works fine, including WiFi.
However, I am concerned about this, because my X200 has an Intel WiFi
chipset, which I know uses proprietary firmware. I am concerned about
this because the firmware could be malicious, so I think this is quite
bad from a security perspective. The more proprietary software, the
worse security you have, as has been shown many times. Since the
hardware is secret, it is possible that the WiFi chipset could be used
to do malicious actions without any way to tell. I am especially
concerned about the firmware being in dom0, which has access to the
hardware.
For many months I used Trisquel GNU/Linux, which 'deblobs' the kernel
with the scripts from the Linux-libre project, endorsed by the Free
Software Foundation. WiFi does not work but I have an external dongle
and at any rate ethernet is often faster. Other than that, everything
else works flawlessly.
Therefore my question is, for a security-orientated OS, what is the
position on the proprietary firmware software?
At the very least, I would like to install Linux-libre in Qubes dom0.
The Free Software Foundation of Latin America (FSFLA) offer the
freed-ora repositories for Fedora, which removes proprietary firmware
packages and installs the upstream kernel (as far as I can tell; I used
it in normal Fedora and it works fine) and free firmware programs.
As a more permanent workaround, will Qubes offer Linux-libre by default?
I think it is best not to include the firmwares at all but maybe that
will be for further in the future.

Thanks,
D.

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Thu, Jun 30, 2016 at 10:57:42PM +0100, Duncan Guthrie wrote:
> Dear Qubes Users,
> I have been using Qubes OS for a couple of days now. I own a Lenovo
> Thinkpad X200 and everything works fine, including WiFi.
> However, I am concerned about this, because my X200 has an Intel WiFi
> chipset, which I know uses proprietary firmware. I am concerned about
> this because the firmware could be malicious, so I think this is quite
> bad from a security perspective. The more proprietary software, the
> worse security you have, as has been shown many times. Since the
> hardware is secret, it is possible that the WiFi chipset could be used
> to do malicious actions without any way to tell. I am especially
> concerned about the firmware being in dom0, which has access to the
> hardware.

WiFi card is assigned to NetVM and have no access to dom0. So even if
its firmware is malicious, it shouldn't be a big problem. It may at most
mess with your network traffic - which should be encrypted anyway for
anything sensitive.

In practice the only firmware still needed in dom0, is the one for GPU
(if applicable).

> For many months I used Trisquel GNU/Linux, which 'deblobs' the kernel
> with the scripts from the Linux-libre project, endorsed by the Free
> Software Foundation. WiFi does not work but I have an external dongle
> and at any rate ethernet is often faster. Other than that, everything
> else works flawlessly.
> Therefore my question is, for a security-orientated OS, what is the
> position on the proprietary firmware software?
> At the very least, I would like to install Linux-libre in Qubes dom0.
> The Free Software Foundation of Latin America (FSFLA) offer the
> freed-ora repositories for Fedora, which removes proprietary firmware
> packages and installs the upstream kernel (as far as I can tell; I used
> it in normal Fedora and it works fine) and free firmware programs.
> As a more permanent workaround, will Qubes offer Linux-libre by default?
> I think it is best not to include the firmwares at all but maybe that
> will be for further in the future.

Generally your are right. But in practice it would mean even more
constrained hardware requirements for running Qubes OS. So, until we
implement GUI domain (which will remove the last firmware-needing
devices from dom0), moving to proprietary firmware-free linux distro in
dom0 isn't an option.

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJXdaVZAAoJENuP0xzK19cs8sYH/i0iSLXPCVWWu9pVOmh/CMwe
YT60yKKQ6mBEl1ENT+5iP52XTgHlSYJd4ocAnMpYnT4+n1bNS+lhM0upg6chgc8M
QWsVHC3E/V41banBIwn0JBUriKLT6LgnYqCXaAT8LNF+bPWlk7lsRkOxpH3UzQWH
ofY8HoWv6MDoNfvEjrge9j0d5nKxRwkF7g0EpHu46czAg72M1jTDMU1jdrtztJGo
cxplHCn9ZunO6I5jgArsdWvsQA0/1ilzZRkIyjXODvSmRhTv1GjcQVnXmZLt11a9
knCI6PXU5WVYcIRtVruHchrr7Z0/DovgcpHZK4FG7yzX8jAThw/8U6wo8vxqo6o=
=3jtI
-----END PGP SIGNATURE-----

[Duncan Guthrie]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 01/07/16 00:03, Marek Marczykowski-Górecki wrote:
> On Thu, Jun 30, 2016 at 10:57:42PM +0100, Duncan Guthrie wrote:
>> Dear Qubes Users, I have been using Qubes OS for a couple of days
>> now. I own a Lenovo Thinkpad X200 and everything works fine,
>> including WiFi. However, I am concerned about this, because my
>> X200 has an Intel WiFi chipset, which I know uses proprietary
>> firmware. I am concerned about this because the firmware could be
>> malicious, so I think this is quite bad from a security
>> perspective. The more proprietary software, the worse security
>> you have, as has been shown many times. Since the hardware is
>> secret, it is possible that the WiFi chipset could be used to do
>> malicious actions without any way to tell. I am especially
>> concerned about the firmware being in dom0, which has access to
>> the hardware.
>
> WiFi card is assigned to NetVM and have no access to dom0. So even
> if its firmware is malicious, it shouldn't be a big problem. It may
> at most mess with your network traffic - which should be encrypted
> anyway for anything sensitive.
>
> In practice the only firmware still needed in dom0, is the one for
> GPU (if applicable).
>

I think this is a good idea in general, whether the firmware is free
software or proprietary software. However, there are certain wireless
chipsets (made by Atheros corporation) which work without a
proprietary firmware blob for WiFi, but don't for Bluetooth, so even
if they largely work without the proprietary program, the operating
system still loads some proprietary program not needed (most people
don't use Bluetooth at any rate). I own such a chipset on my desktop
computer; Debian works without any proprietary software at all, while
Tails loads firmware for the Bluetooth. What is the answer to this, do
you make exceptions for firmware only for wireless cards and GPUs? Or
do you just allow them all through.

Another thing I have read is that Linux-libre's deblob scripts don't
just get rid of firmware that is proprietary, it removes all binary
files disguised as source files (e.g. some binary file named
"something.h") and "obfuscated" driver sources (I believe that the 2D
nv driver has been accused of this). Would you consider at least
adapting the deblob scripts from Linux-libre to work for your kernel
to only allow select firmware through, for the most common computers?
Another option, like Debian (and, if I recall, Ubuntu to some extent,
although I have never installed Ubuntu), which I think would be even
better is to have a completely free kernel by default, then a separate
repository for firmware, which can be enabled in the installation
process. It would probably be considerably simpler than adapting the
deblob scripts to be quite selective, too. It wouldn't make Qubes
compliant with the Free Software Foundation's "Free Software
Distribution Guidelines", but I think that from a security perspective
it is better than including the proprietary 'blobs' by default, and is
a balance between usability of obscure hardware and security of dom0
(it never hurts). What do you think of this proposal?

- ----
Thanks for your reply, it was really helpful for allowing me to
understand more about your security policies.

D.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJXdb3qAAoJEPs8tiiQ8FTAf4wQALdWB123VGv9OdisLfI2OQda
6r6IyVWPny+shAuoxfiui+0HmkHZB8CMaAleLGmyOo+iWT8jBiTbqV8qMTfWO9kL
My1TUuvEB12s7RGecqKxRlz5ij1cmnpbCg2yXM1qfEpFLYtw9d9agw4fEiSOCokY
aF7nuPeLXZjp91mSaTRRV/U4JXd09XFU1/dULNUv+0Pmr7uT+8ZhlLdGHaRoN2SV
+AmgVQdtnRoIsJWRrEeT9CG6KS5Z7+JmGNcOfVIW9CSa2WFG+JFbiJEyfo26IciP
ofAMzqapBWZwzlxJ6pNriGgacYeyHKMJwBK34RCebuyrpreLU5QutxZ3avO9yoHh
JUqNdffcwlL43noZ89i9SIV+wYcB9Nj9PvUjPzCuxXMfFHkaNJ4cI17N/mLZzKXc
0SCKn5DAFjOz2wBQ/M4KTYoBfPbj0HWkBlbNdHNYzIutfMWG5NbMkIbph46tjWkF
yThTSZZoCLChhZ0OAnEc7vNLCcwCVArXo6P0L+FDdAMDTVLxk8CaFOuhIWFQXnG1
Q20K3sTlTh2pPjf2bvEXNlFOBQ2H7tHV4YVyyoqsEsFyr3aq4KiEUcffhWma6Y8H
5XT405xg80/17L2sHYJciE+k6U9C1tpJe2BYYnOWrId3E72gL+AGpnB3h9J/6s/g
tvxD9xDk5VSpnb13dnJb
=WZ6b
-----END PGP SIGNATURE-----

[raah...@gmail.com]

I think what Marek is saying is that from a security standpoint it doesn't really matter because the netcard is isolated even at the hardware level with iommu supported system. And if it messes with your network traffic you should be using encryption, https or tor etc..

I think the reason they are not adopting such kernel is cause qubes is trying to get more users and hardware compatibility is the biggest hurdle and turn off to people. Its still new type of os and people are hesitant. Also most people use laptops and wouldn't be as willing to buy an external usb network card for qubes. Which might also be troublesome in some cases when trying to isolate usb controllers.

[raah...@gmail.com]

Btw, I also love trisquel for the same reasons :)

[Duncan Guthrie]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 01/07/16 02:05, raah...@gmail.com wrote:
> On Thursday, June 30, 2016 at 8:49:16 PM UTC-4, Duncan Guthrie

> ---- Thanks for your reply, it was really helpful for allowing me
> to understand more about your security policies.
>
> D.
>
>
>

> I think what Marek is saying is that from a security standpoint it
> doesn't really matter because the netcard is isolated even at the
> hardware level with iommu supported system. And if it messes with
> your network traffic you should be using encryption, https or tor
> etc..
>
> I think the reason they are not adopting such kernel is cause qubes
> is trying to get more users and hardware compatibility is the
> biggest hurdle and turn off to people. Its still new type of os
> and people are hesitant. Also most people use laptops and
> wouldn't be as willing to buy an external usb network card for
> qubes. Which might also be troublesome in some cases when trying
> to isolate usb controllers.
>

I understand what Marek is saying. I'm saying that ideally we
shouldn't let any proprietary software by loaded by dom0, because we
simply have no idea what it does. For example, someone could pressure
the people who write the firmware to put something nasty in it
designed to attack Qubes and TAILS users, to exploit Xen and break out
of the hypervisor. It is a distinct possibility, considering we are
living in the age of Orwell.
What I am proposing (nonfree repository turned off by default) means
that we can have hardware support while ideally avoiding the
proprietary software as much as possible. If it works for Debian and
Ubuntu, then I am sure it would work for Qubes. For instance, this
might be easier if dom0 was based on Debian, as I am aware this was
discussed.

I am also still confused about how I might install Linux-libre in dom0
and replace all the proprietary stuff with the packages from freed-ora
repositories (or my own). I think a guide in the documentation for
this would be good. Does anyone have any ideas?

Thanks for your reply,

D.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJXdlgOAAoJEPs8tiiQ8FTA8MEP/A+Y2AjpMVNVFb6wMAKnZxd5
rSBhdXxBL6Evfz5jq3J+a2ApOkmv/GCaZ2rn7V+tcu7mEs2Uwd8vEaoD9PJSZA2Z
bwiGis8be3ysK7eBSUa0OUCkYF7GMN7H0T1nVrL5GtYqbAODq8MOe0fWnPKTUU0h
3C7c5ffXpFxhxPS9/IbMnBisnNbr55hxAcSbklY0Wjl/6b7URp10tPpkyN3RW7zi
u+HgCdi9MQXotTbzCr7KCPwJ1G3U/5aC1+uaSKZKQAGcRNTKEDuupwBEce2VcdpV
wIIF6oqSSXUbK9m73+hE/i/meTq+66Hm8yv6fNHNZbtulpngMrqTKjpnOZOzLmO6
ZPTXcj6Tcjj1AaZ89Ym06wtQTgmCI90LVV/A8xx6X0euELILBc0NSp2vLNR4tdkJ
Czvh6+fp65Q+qC8u48QeiIajqtW7XDbrUkgGHX0kVEVnxJ9aVu43TOEe4kYd+P/t
JBZqlnIS2fIb8594OQnBc+ivqees4/nBZLbBlfLYrK+btHnvvzEHdm6jI/bFvkqX
1kKGox5z5h+WwgLYKEC7OnrWQZ9pt8eianUrs9388Lsc6aW6q/26svdik3yFP6Mh
Rn0Too0GumOPI9+KV7Cu0BO5cSMfQkeFnjCaw+TeBT3qvYhEqlQ0mz5pSB15w53p
4HzeUKZAwW+NdYnGYRbq
=n4PG
-----END PGP SIGNATURE-----

[Alex]

On 07/01/2016 01:46 PM, Duncan Guthrie wrote:
>
> I understand what Marek is saying. I'm saying that ideally we
> shouldn't let any proprietary software by loaded by dom0, because we
> simply have no idea what it does. For example, someone could
> pressure the people who write the firmware to put something nasty in
> it designed to attack Qubes and TAILS users, to exploit Xen and break
> out of the hypervisor. It is a distinct possibility, considering we
> are living in the age of Orwell. What I am proposing (nonfree
> repository turned off by default) means that we can have hardware
> support while ideally avoiding the proprietary software as much as
> possible. If it works for Debian and Ubuntu, then I am sure it would
> work for Qubes. For instance, this might be easier if dom0 was based
> on Debian, as I am aware this was discussed.

What you say is not wrong, but also not new, and that's exactly the
reason behind netvm and the planned (but harder, hence not yet ready)
guiVM. If everything goes according to the plan, with GuiVM there will
be no need for opaque binary blobs in dom0, and any distribution may
well be used - dom0 still does not have any networking, so apart from
not-yet-found malicious code in the FOSS in dom0 there should be no
security problem.

The fact that it might be easier if dom0 was debian based is wrong: it
would be exactly the same. As long as someone needs support for nvidia
and chooses to install the official nvidia drivers, they will have
opaque binary blobs in dom0. With fedora it's exactly the same: by
default there are the foss nouveau drivers, but if someone feels
inclined, they may well install the official (opaque) nvidia blobs.

If that same person is happy with nouveau, they may use it both in
debian or in fedora.

If you find any other unneeded suspicious package, you may just remove
it with the package manager; please report back what you find, so that
dom0 may be "purged" if these packages are actually unneeded in every case.

> I am also still confused about how I might install Linux-libre in
> dom0 and replace all the proprietary stuff with the packages from
> freed-ora repositories (or my own). I think a guide in the
> documentation for this would be good. Does anyone have any ideas?
>
> Thanks for your reply, D.

The problem with a custom dom0 is that it has to support being a Xen
hypervisor administration domain. If this pre-requisite is met, then you
may try to port the qubes tools to work in your dom0.

I still don't see your point in doing that, anyway, apart from the video
card opaque blob (explained above). As an example, I do not have any
NVidia card as of now, so I don't have any opaque binary blob in my
dom0. Could you please list what other non-just-removable "proprietary
stuff" you found in your dom0 and explain what would you replace it with?

--
Alex

[Duncan Guthrie]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Thanks for your reply! However, I think I need to clarify some things
here.
Freed-ora is a repository produced by the Linux-libre project which
provides a kernel without the proprietary firmware programs, and a
package which removes and prevents installation of non-free programs
(mostly firmware packages for various devices, such as bluetooth
dongles). It would not require any modification to Fedora in dom0
other than enabling and installing the freed-ora packages. I do not
know if Qubes makes any modification to the kernel, or it just uses
stock Fedora kernel.
Regarding graphics, I am not talking about the Nvidia binary drivers -
Nouveau works perfectly for most people, and can be used without
proprietary firmware (although recent Nvidia cards require signed
firmware from Nvidia, but the driver is open source). (The Nvidia
binary drivers, if installed in dom0 are running in kernel space,
which is utterly stupid. I can't see a way that people would be able
to put them in a special GUI domain). It is their computer and they
can install what they want.

What I really want is for Qubes not to include the proprietary
components by default. This is as simple as the installer saying
something like:
"The installer detected your computer requires proprietary firmware.
Your computer may work fine without the firmware. As Qubes does not
have access to the source code or is unable to modify these firmware
programs due to license restrictions, we can make no guarantees
regarding security, although we have taken steps to mitigate the
problem through Qubes' design. Would you like to enable the firmware?
[recommended: no]"

Keep in mind this is by default. It is not as if we are saying these
people can't use Qubes without the firmware, and indeed we are giving
them an easy way to enable it at installation, and they can install it
later through the package manager.

Thanks for everything,

D.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJXdngqAAoJEPs8tiiQ8FTAch8QALbj7xkewSnBWxXZSBEeaJXJ
XOS4JUxu7r7L5pHXANEo7jdW1/Pf6goZXjDQQlqCSdEwXiRBlcuDZU5pz//LrdFr
BAtcdc71K7YRmusByRCfaVoRL8XsboKxob8d19oI1q6/AtKL5uY4dulbvHXzxT2P
lwQECS3g+fNDZPLOYAH/p643zld8tFgE6LcyfG189krSM9JMI7R71terp30Vtyq1
WBILHWJJiy1fMphGKjS6Hc21JPi3NPJBG8SXEnyJcDyppaLgeFwRSvrz5M4BCROU
H6XkvrZPNf73/OW9NAcxwRMzmaODsrnYg/yM/EjS+EppCZGj5AzALfAxOt61zGjV
AE8hHWBXdbpenfVXdSKaJpGa44lVsw6pn/g7S3IQMI0ylabZxyWs6wAEm81LZOd/
QMENFJ65mz3xkjGspKv+rnIX671zZuHij9+93YBdXCYlygQ6CTq3i8aT5f2DrdNN
kQsvLpwzFBPNKGLjXQBm83qtuM0Z2+R7eEdJsL/6pn1kkn41S2gdjDuGlNoFTu88
C5bXX0ksTXMKYxnYC4+Dw8nvp+qI+m/nBxPexn5Dye6sb4h17aAjglSWamB7+iYv
A+tRMckxAmb5MAMpVw9f8Ay4YucZEUfN6A2QGnJLxEGYx9Njj6SVgdSK8bEAz5/i
T1orv7cELhSjCK44FrlA
=Qs68
-----END PGP SIGNATURE-----

[Alex]

I stand my ground that this would not increase security against targeted
attacks. I concede that it would be a nice goal for the FOSS movement,
but nothing more. Let me explain.

In normal linux distro, opaque binary blobs are disliked mainly because
they may contain unintended security holes that cannot be verified nor
easily patched, and become unmaintainable shuld the providing entity
disappear out of business. Then there is the FOSS promotion stuff and
so. Last and least, there is the intentional malware inclusion
possibility; which is rarely practical, because opaque binary blob
makers do have economical incentives in keeping it simple, working and
in defending their brand name from such allegations.

In qubes, the driving philosophy is taking those opaque binary blobs as
necessary evil, and isolating them as much as possible in a way to
contain their danger. The NetVM is a brilliant example, as is the GuiVM
(which is not nearly as impossible as you make it sound). So yes, there
may be opaque binary blobs, and it may be a better world without, but in
Qubes they cannot do much damage *by design*. They are disliked in dom0,
and the general direction is to get rid of them from dom0 as much as
possible: the only elephant remaining in the room is GPU drivers, and
GuiVM will work around that point.

As for what can be hidden by *intentional* means in open source
software, I invite you to read and understand the spirit of the
Underhanded C Contest: http://underhanded-c.org/ . My take on FOSS is
that having open source software is absolutely nice when it comes to
fixing bugs faster in production code, and that it is a guarantee on the
writer going out of business, but no, having FOSS is not by itself a
guarantee against targeted attacks.

Or are you really, seriously going to audit a linux distribution for
underhanded intended effects? Did you remember that someone already
tried to do that to the linux kernel (http://lwn.net/Articles/57135/) ?

So my take on the strength of Qubes is the philosophy of 1) living with
necessary evil, and containing the damage or eliminating it by design
and architecture and 2) preferring less code instead of more, even if
supposedly more secure, because all code contains bugs, and some bugs
may be security holes. The vast majority of the bugs may be unintended,
but FOSS alone is not a guarantee of no intended bug being present.

TL;DR: I understand your point, but I don't agree with that, and I will
be completely ok with opaque binary blobs once we'll have a GuiVM.

--
Alex

[raah...@gmail.com]

Ubuntu and Debian don't do that. So i'm confused by your statement. They have repos, on by default, for proprietary firmwares. That is something trisquel does which 100% libre. not debian or ubuntu, imo.

I used trisquel for a while and loved it. Loved how it was very light and everything could be accounted for easily in the logs, and it prevented me from accidentally installing some binary blob. It was my distro of choice for compiling grsec kernel because it required no tweaks to anything, unlike any other distro. But eventually I had a need for some proprietary firmware and switched to debian on my baremetal machine.

And like ALex says, even if not it doesn't mean that you should then totally trust your free firmware. You are just as much at risk as anything else imo. You still have to trust the people writing it, unless you are reviewing the firmware yourself. Sure bugs will be fixed quicker hopefully, but you should still consider it a security vulnerability that can be targeted.

Maybe a libre kernel could be an option, I see nothing wrong with that. But to take away the freedom of people who want to use proprietary firmware for certain devices is probably not something Qubes is gonna do. They are trying to reach wider audience to get adopted by more people at this point and hardware challenges can be a problem. I for one would never want to run proprietary firmware on my qubes machine, and maybe eventually qubes can afford to take such measures to prevent them, but I definitely wouldn't advise that now.

[Duncan Guthrie]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

I know that Debian, in the default install, only enables 'main' if you
require no firmware. The installer does not include the proprietary
firmware; you have to insert it on removable media. The repositories
are separated: main -free software only, contrib -free software that
requires or enables proprietary software in some way, nonfree -nonfree
software. Ubuntu has restricted which is the same thing although this
is enabled automatically in many cases (although you have to make a
conscious effort to turn it off). That is what I am proposing. I don't
know what you all think.

Now, coming back to my original question: how can I install
Linux-libre? What Qubes-specific patches are there to the kernel?
Would I be have to rebuild it and apply the deblob patches, or is
Qubes considering providing it in the repositories?

Thanks for all your correspondence,

D.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJXd2hvAAoJEPs8tiiQ8FTA+b0QAJGIiehefQTZqcI4w/yZhXty
HDn08+lsRUaNLA44YVsj6rHbJ30jvut/8DgKWw4RFVicMJPSKzYjzdtPpVtTWgSk
YFeGFM0gus7pYvnzyL1LcjiHhnkO1nEz7wUAAu9FgaTHhy6ZFPR2egsls6s8l3gL
mndCrdmyTkmrl++ewrF3i22lgYzMJvbWaC1fS9DfufjhXTTVMy5NvB4oY8fd+52o
7hE4kkRRfOtyknHUz9LIRO9ddl81mrjjh7k8Khwa/Nm+1EQoHZ+5Lc5hyulDqlBE
bF1b7LroiAa+JEf5geU9bwZfC3q16UOCEd7Ci1EoCk6yiyGeCpI/iSXS6gjNANNM
ulI9m3t81qAR1w8kIin+h1B2sGa17xdFmZecfkEGhkfKUfpCgbowvOOjuIOPMKcj
vpM5VDNjsrK/9eAaPKm4acbhncz6S8B8TtQsBXqBIVUYE2wLCZo/8qgEgAiJ7Rpr
6yoPT5Yn+1w1+4dIaHNBQX28ZjfSCRaf66KZ32pSW5YBbOCANPViiDuvLVLgBb5e
Uh94GomY91nv0Ec49vXuqT7FP5Q3TpW+0RR4qbNO7oo83YMGG49DsjqYp4hyF+f4
e7b/08fY9ZlBEBRFqwjgAzTyJp8p/Ni/z4VqbBckEgdQsWNM3Mz1l4FpAVDi9L6a
TwWkNCneIz8dOYQQxK9Y
=0GO4
-----END PGP SIGNATURE-----

[raah...@gmail.com]

well compared to trisquel, on ubuntu and debian you won't have to buy a usb dongle to get a wireless connection. And you won't have to add any additional repos.

As far as linux libre, I'm not sure about dom0. Someone else probably knows. But you should be able to install it for template vm.

[raah...@gmail.com]

You can probably just copy kernel config from dom0 kernel. Hopefully someone corrects me if I'm wrong. Template vm is what uses the network firmware, its what the appvms use, so thats probably where you would want the libre kernel anyways.