Question about nonfree software in Qubes

[D G]

Dear Qubes developers,

I am interested in Qubes OS because of its design. However, I have a
question about what software is included in Qubes, and whether it is
free or non-free, particularly the Linux kernel.

I have been using Debian GNU/Linux with a grsec-patched Linux-libre
kernel for some time. I use only the main repository as this is just
free software, which is more secure because it can be audited.

According to your FAQ, Qubes is not GNU Free Software Distribution
Guideline compatible "for the same reasons as Debian". I would like to
clarify what this means; do you include any non-free software in your
repositories? Does Qubes include the non-free firmware that is included
in the upstream Linux kernel, or is it separated like Debian is, with
only the free software included by default? Do you use the Linux-libre
kernel patches, and if not, since Qubes uses RPM package manager, would
it be possible to use the Freedora repositories produced by the
Linux-libre project? Does Qubes use Grsecurity to secure the underlying
OS that hosts the AppVMs?

Thank you,

D

[Unman]

It would perhaps be more accurate to say that Qubes is not Free "for the
same reasons as Fedora".
Qubes is built on Xen. dom0 uses Fedora, and therefore does not meet the
FSF guidelines because non-free firmware is included. Individual qubes
may be based on Debian or Fedora - neither meets FSF guidelines. To that
extent, there is non-free software in the Qubes repositories - the
templates.

I see no reason why you shouldn't try using Freedora repositories, and
rolling your own kernel with the Qubes patches.

Qubes doesn't use grsec - it's come up on the mailing lists quite often,
as a simple search will show you. Micah Lee has also written on this:
https://micahflee.com/2016/01/debian-grsecurity

unman

[Chris Laprise]

For people using a libre BIOS, running a distro like Trisquel in dom0
would be very attractive.

Having 100% libre in domU is less of a (security) issue IMO, even for
these people. I think that's why ITL wanted to support Windows early on.

Chris

[Marek Marczykowski-Górecki]

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

Yes, that's right. But for this to make reasonable platform for Qubes
OS, such libre BIOS need to support VT-d. As far as I know, none does.
Unfortunately.

- --
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

iQEcBAEBCAAGBQJXdc80AAoJENuP0xzK19csat8H/3pbXPevzwfhY05zRV6t5Z5D
wItpyuKfc/EuvtYxVOgMM5fL6bG9lMqdFq9q62F6FNjCbtbwP938FFm+NIjJrV6B
4z5rCbwk5TcNEx4ozLTQeFMDK02JLeWQaJWXyJp4x9+S5abjOMz+8oU1qg56mQw8
q7QVzpBjbpXutScLNIlRLzb70xeyFAn9LDO8JSr3kAhFB9bUnHOgZq49leuagSqv
E/zJLGMVfHQZN0O68OZLpLEO1irMiT3NzSoNKdxHoWWgVZs/G8VMplowkOSdYUI+
iJ+0icYS6kli9qewF3o14/etq46YGNj3Z6xPB7KNmKZ61BKxuVX7UqyR7MQE4iY=
=fqKA
-----END PGP SIGNATURE-----

[Duncan Guthrie]

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

I don't really care what we run in dom0 as long as I am pretty certain
it can be audited. At the moment, the Linux firmware is a concern for
me because we simply have no idea what it does; it is a distinct
possibility that someone could have leaned on the people who develop
the firmware to add something really nasty, such as something designed
to get code to run in userspace and attack TAILS and Qubes users (or
anyone). If Debian and Ubuntu can manage to separate the repositories,
then I think Qubes should too. Having less proprietary software
running in dom0 (which has access to hardware) is better as it reduces
the attack surface.

Thanks for your reply,
D.

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

iQIcBAEBCAAGBQJXdln5AAoJEPs8tiiQ8FTAsBYQAKtlTmtT/qUtTWGdQTfJieeF
S0ytCIpLnXqoLOiakvhRWi5xCKVkRGi3RX5VI3blpifz5qzU8YDFVpdwZpcRGzhg
RY2ffZELdZ8TjHdfwmEx87ONjStxgd5NPFseEsoRhsUmCsiB/3454q/X/zGQLPD7
BWp9s3AQBKNq1HgJz00HF9kry9szm9xbDwlociCB4VCRPSpB8QkM51V/tlqyS6df
6CKLWspRLA3NWSCuGOS595GZqxzP+aIMf63I3GNg1Pa9/79rAwM+NbnQATF9JOAY
m7nxXNLg6ezLgVjmS+UJ+e+0eW0PgEeuywZC7Wb2n4yBR/xv7WzRGksnNbtTHqyX
4tl86TRxZxWEUlM02MtFNmnUCg6ygvQPWhGDo4syZj6PZuTML/9o6JIZ9ddElcdt
8xWaFUzKb3GOB72MYzwzoIl/AsAYW4FPpx0pZbtwBSqY34M8ls/vAEcRXSEFqLvE
AWBt8oP/KrmT/iUyf/r3t1mG64amsrkIWpoo4E0mhwaOOitANbGTFCReAM6CVaqE
u1cnnZHF3TfdejP4jdlL/vzEvi8cAymsl+qoioU4pOtDigiL0eXmwkGSnFt0QvLI
mFlvEezR4YiaAqPz9UnKH5QTr+Ahsk2Zx/SYMItlG/xIOCComoDRPe66JpPThIQ2
TDEk7P9qO8Qom/4fdLii
=p9fF
-----END PGP SIGNATURE-----

[Duncan Guthrie]

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

On 01/07/16 03:02, Marek Marczykowski-Górecki wrote:
> On Thu, Jun 30, 2016 at 09:51:25PM -0400, Chris Laprise wrote:
>> For people using a libre BIOS, running a distro like Trisquel in
>> dom0 would be very attractive.
>
> Yes, that's right. But for this to make reasonable platform for
> Qubes OS, such libre BIOS need to support VT-d. As far as I know,
> none does. Unfortunately.
>
>

Libreboot removes all the proprietary software that is normally needed
to boot the computer, including the Intel Management Engine. As far as
I know, Qemu in dual core mode and Qemu-kvm don't work in some cases,
causing a kernel panic. Coreboot, on the other hand, leaves the Intel
Management Engine software intact, so you don't get rid of the worst
spyware (for that is what it is, in the wrong hands). I'm not sure
what this means for VT-d and Qubes, though, because I haven't managed
to install Libreboot yet.
Looking around the world wide web, I have found this page on VT-d,
which appears to be a special virtualisation mode that has access to
the peripherals: https://en.wikipedia.org/wiki/IOMMU#Virtualization
Here is more info:
https://en.wikipedia.org/wiki/VT-d#I.2FO_MMU_virtualization_.28AMD-Vi_an
d_Intel_VT-d.29
What I am confused about is that is says that VT-d is "included in
most high-end (but not all) Nehalem and newer Intel processors". This
suggests that my computer, the X200 based on Core 2 Duo processor,
will not run this as VT-d is not supported.
Does Qubes require VT-d, or just rely on it with certain features? At
the moment, my computer seems to work fine with Qubes, and does not
appear to support VT-d, although I am confused about how I would check
this.
Therefore, my question is, would a libre BIOS going to boot Qubes at
all? Perhaps it would boot, but just with fewer features? Does anyone
have any information about this? Once I install it I suppose I could
test it and see.

Thanks again,
D.

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

iQIcBAEBCAAGBQJXdl4IAAoJEPs8tiiQ8FTAOpsP/RJ+l6xMaHhhJ5mIdozFTMTm
fCjrgGcr4+wxy4NCm/eTa2zqoW6urzM+4SKMphWq4G5TA86uqaKaJ9/qptREWzKg
1dAVwtHHeTGabXqZyIZScYLSPRusdsmPTnsV1i/UBSeFrjROuG/0fb8c/Aev+w73
vaWqqNR9xeHcFB3SJ+RZ5iE1y51Bks/dxvoyHBftj6d5swNf8mo5iURrc06XBChk
KZBeMRkWNLhAjpi02pfNs9z+1Hl3IJ51XkvdwAPWE1wrYnmbOYO4V5nF5NBZUP08
LWE07QjRSmeE7pZqv8c2JBWX5bZSgvq+urP36pp3qMLCnBOTZicpgVCsztgy7qtF
hd0EhCVy7To0Syo93QBGdXx6dp5XR+JEKg/Y+ckM4ihM/MBmsGahs0lL92rv4dwv
QXt62muXa+aZjnYcak+RpoLp4X3Js1YOGH5l/NH+VaeRoAJiEAZ5+62ReVI+lqf1
QhgBiCAEGZ+haD/ZTLHCmhwryZOywab1gCpqkgyXs0cu1HcqAVk0QGvsRDuDT+V5
rK6hOPb3X72ivCaVI2tp3Tq4UqgeuyIcy5ep0p/prH2roYCtJzRNkHLNMOC0FE8X
SYa9lNl5SIECkdSJWZsiw//GBwHlqoR564h9InTGxirBYKGMGE/ci6+jBtAskknZ
hObS2ri3o0RGLPqE9blJ
=uoTO
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

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

On Fri, Jul 01, 2016 at 01:12:06PM +0100, Duncan Guthrie wrote:
>
>
> On 01/07/16 03:02, Marek Marczykowski-Górecki wrote:
> > On Thu, Jun 30, 2016 at 09:51:25PM -0400, Chris Laprise wrote:
> >> For people using a libre BIOS, running a distro like Trisquel in
> >> dom0 would be very attractive.
> >
> > Yes, that's right. But for this to make reasonable platform for
> > Qubes OS, such libre BIOS need to support VT-d. As far as I know,
> > none does. Unfortunately.
> >
> >
> Libreboot removes all the proprietary software that is normally needed
> to boot the computer, including the Intel Management Engine. As far as
> I know, Qemu in dual core mode and Qemu-kvm don't work in some cases,
> causing a kernel panic. Coreboot, on the other hand, leaves the Intel
> Management Engine software intact, so you don't get rid of the worst
> spyware (for that is what it is, in the wrong hands). I'm not sure
> what this means for VT-d and Qubes, though, because I haven't managed
> to install Libreboot yet.

Yes, exactly. Currently in practice you can either get rid of Intel ME,
or have working VT-d. But not both. What is more important really
depends on threat model, but I'm in position that having VT-d is more
important. Because potential backdoor in Intel ME can be use only by
very narrow group, but DMA attack (against which VT-d protect) can be
preformed by anyone able to run something in NetVM (which is quite easy
because of complexity of network protocols - for example bugs in DHCP
client).

> Looking around the world wide web, I have found this page on VT-d,
> which appears to be a special virtualisation mode that has access to
> the peripherals: https://en.wikipedia.org/wiki/IOMMU#Virtualization
> Here is more info:
> https://en.wikipedia.org/wiki/VT-d#I.2FO_MMU_virtualization_.28AMD-Vi_an
> d_Intel_VT-d.29
> What I am confused about is that is says that VT-d is "included in
> most high-end (but not all) Nehalem and newer Intel processors". This
> suggests that my computer, the X200 based on Core 2 Duo processor,
> will not run this as VT-d is not supported.
> Does Qubes require VT-d, or just rely on it with certain features? At
> the moment, my computer seems to work fine with Qubes, and does not
> appear to support VT-d, although I am confused about how I would check
> this.

https://www.qubes-os.org/doc/user-faq/#can-i-install-qubes-on-a-system-without-vt-d

> Therefore, my question is, would a libre BIOS going to boot Qubes at
> all? Perhaps it would boot, but just with fewer features? Does anyone
> have any information about this? Once I install it I suppose I could
> test it and see.

Yes, it will work, but will provide weaker isolation of NetVM (and USB
VM if you choose to use one).

- --
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

iQEcBAEBCAAGBQJXdoHYAAoJENuP0xzK19csnckH/0Sve4Yd1BDS8XOBeF+bYhZw
s0wb6PVUrWmAEBoWziXLJxlWvI/1804caBkegGDqLx0xYJTNkdVAY7Yf5Kgvot4k
Nm0Wrum3ObPFGPL3OnVqdmvnsScvRgDhYQbLEuuBUYyAztGwBBfBdbzaU5vaNhMN
q1pBub+KDcHmYRkp5cmhhEQE2Bmq4NtANIC3Cdd0fh8ibUJtBpZUsTXpUZ0gV7bD
h+uB+E/QShF8IdkD0mChKqQ7H/dxxGQ48GJANM6n/WVIKLRRCqfOIirg+sZHZN8+
W2leftxpzqW+yzn5pblMWtnhI/7ou8jQDmF0QNC1HqLToxz+TYIiePwxoL3OmiQ=
=aXaP
-----END PGP SIGNATURE-----

[Achim Patzner]

Am 01.07.2016 um 13:54 schrieb Duncan Guthrie:

> I don't really care what we run in dom0 as long as I am pretty certain
> it can be audited.

What about microcode updates? 8-) I'm pretty sure many people with more
recent hardware would be quite upset without them...

> At the moment, the Linux firmware is a concern for me because we
> simply have no idea what it does; it is a distinct possibility that
> someone could have leaned on the people who develop the firmware to
> add something really nasty, such as something designed to get code to
> run in userspace and attack TAILS and Qubes users

In that case you might be really picky about wireless hardware; it is
reasonable to assume that certain vendors do not really do a good job at
auditing the parts of their firmware dealing with (MAC level) management
tasks and having someone hack you using the management layer of a
wireless network would be very elegant and ugly at the same time. An
attack like that using DMA capabilities to pull the memory rug under
your CPU's behind doesn't seem too unreasonable.


Achim