Non-free firmware in Qubes OS: is there such a thing?

[Vladimir Shipovalov]

Good day! According to GNU.org description , Fedora in its standard distribution includes certain kinds of

closed-source firmware (binary blobs) which could pose a threat to security.  Because Qubes OS is based on Fedora,

I would like to ask you: are there any closed-source blobs in Qubes OS as well? (proprietary graphic drivers, Wi-Fi firmware, etc)

( I hope that Qubes OS is 100% free and open source, without closed-source blobs,

like these operating systems endorsed by FSF: http://www.gnu.org/distros/free-distros.html )

[Andrew B]

On 10/09/14 21:10, Vladimir Shipovalov wrote:
> Good day! According to GNU.org description <http://www.gnu.org/distros/common-distros.en.html> , Fedora in its standard distribution includes certain kinds of

> <http://www.gnu.org/distros/free-distros.html>
>
> --
> 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...@googlegroups.com <mailto:qubes-devel...@googlegroups.com>.
> To post to this group, send email to qubes...@googlegroups.com <mailto:qubes...@googlegroups.com>.
> Visit this group at http://groups.google.com/group/qubes-devel.
> For more options, visit https://groups.google.com/d/optout.

I think you answered your own question. Qubes is based on Fedora and uses the regular Fedora repos. Fedora includes non-free firmware by default. Yes, Qubes will (probably, depends on your hardware) use non-free firmware unless you take specific measures to prevent that from happening. Some devices (NICs, USB controllers, etc.) can be assigned to backend domains other than Dom0; this isolates the damage that can be done by malicious/buggy firmware for those devices, assuming VT-d works correctly. These domains could also potentially be "completely free" OSes. When/if ITL adds support for a different Dom0 distro, you can do the same with Dom0. You could also use free replacements for those non-free blobs if such replacements exist.

I agree with the need for open, auditable firmware, just like all software. But Rafał raises an important point: you will certainly also use non-free firmware somewhere in your system. More broadly, even RMS, who uses a crippled laptop in order to avoid non-free firmware, must still trust a whole legion of people and vendors and has extremely limited ability to audit his hardware. A bug in or covert malicious modification to any one of these parts can subvert your entire system. It's smart to reduce your TCB--or at least make more of your TCB auditable--but don't rely on free firmware as a panacea... instead, use an abacus, invisible ink on gum paper, and plenty of tinfoil ;).

Andrew

[Joanna Rutkowska]

On 10/09/14 21:10, Vladimir Shipovalov wrote:

> Good day! According to GNU.org description

> <http://www.gnu.org/distros/common-distros.en.html> , Fedora in its

> <http://www.gnu.org/distros/free-distros.html>
>

Aren't you bothered by having closed source BIOS? And what about your
processor? ;)

[cprise]

I'll bet he is bothered by them. But I'd also guess you didn't
distribute the BIOS or processor to him. :p

The desire to have open design for all of the privileged parts of the
system is certainly an understandable one.

[Radoslaw Szkodzinski]

On Fri, Oct 10, 2014 at 2:51 AM, cprise <cpr...@gmail.com> wrote:
> I'll bet he is bothered by them. But I'd also guess you didn't distribute
> the BIOS or processor to him. :p
>
> The desire to have open design for all of the privileged parts of the system
> is certainly an understandable one.

It'd be interesting if there were a laptop with coreboot in it and TXT
support as well...
Even more interesting if someone booted Xen on it with working IOMMU support.

Has someone done this?

--
Radosław Szkodziński

[Joanna Rutkowska]

Everybody is free to take the sources we publish, modify them at will
(to e.g. exclude anything one doesn't like) and build their own ISO.

j.

[Vladimir Shipovalov]

On Friday, October 10, 2014 12:09:10 AM UTC+4, Andrew B wrote:

I think you answered your own question.  Qubes is based on Fedora and uses the regular Fedora repos.  Fedora includes non-free firmware by default.  Yes, Qubes will (probably, depends on your hardware) use non-free firmware unless you take specific measures to prevent that from happening.  Some devices (NICs, USB controllers, etc.) can be assigned to backend domains other than Dom0; this isolates the damage that can be done by malicious/buggy firmware for those devices, assuming VT-d works correctly.  These domains could also potentially be "completely free" OSes.  When/if ITL adds support for a different Dom0 distro, you can do the same with Dom0.  You could also use free replacements for those non-free blobs if such replacements exist.

I agree with the need for open, auditable firmware, just like all software.  But Rafał raises an important point: you will certainly also use non-free firmware somewhere in your system.  More broadly, even RMS, who uses a crippled laptop in order to avoid non-free firmware, must still trust a whole legion of people and vendors and has extremely limited ability to audit his hardware.  A bug in or covert malicious modification to any one of these parts can subvert your entire system.  It's smart to reduce your TCB--or at least make more of your TCB auditable--but don't rely on free firmware as a panacea...  instead, use an abacus, invisible ink on gum paper, and plenty of tinfoil ;).

Andrew 

Thank you for such a detailed answer, Andrew!
If Qubes-OS is protected by design from security threats that could possibly come from some non-free device blobs,
by isolation : that makes Qubes OS not inferior in this relation, if compared to Trisquel and Parabola.
P.S. Tinfoil hat amplifies the signal. Should use mu-metal hat instead ;)

[Vladimir Shipovalov]

On Friday, October 10, 2014 1:21:17 AM UTC+4, joanna wrote:

Aren't you bothered by having closed source BIOS? And what about your 
processor? ;) 

I am more bothered by the fact that modern Intel CPUs contain a secret radio chip ( Intel anti-theft 3.0 technology )

which could allow to remotely disable, or erase the data, from any modern Intel-based computer.

Intel CEO have dodged the NSA-related questions during the interview for a reason...

Unfortunately, judging by Hardware Compatibility List of Qubes OS,

it looks like that Qubes OS is mostly aimed on Intel-based computers rather than AMD

:-(

Also, System Requirements page tells that:

1) Intel integrated GPUs are strongly preferred

2) There could be compatibility problems with NVidia GPUs

3) AMD GPUs haven't been tested at all

AMD hardware has the worst support by Qubes OS - but, because of the mentioned problems with Intel,

that wouldn't prevent me from purchasing MSI laptop that is based on FX-7600P - best AMD APU for notebooks.

This laptop has both AMD integrated (Radeon R7) and discrete (Radeon R9 M290X) graphics.

Of course I will have problems with that pair, but maybe I could improve Qubes OS support for this hardware...

Had some development experience with Linux kernel modules in the past

about BIOS: although there are some coreboot-based laptops, they are very old and impossible to find for sale.

That is a major problem with coreboot project: by the time the support for specific hardware is introduced and perfected,

it is already "End-Of-Life". For example, HP Pavilion m6 1035dx (latest AMD-based laptop that is supported by coreboot)

is 2 years old and has mediocre performance

[cprise]

On 10/10/14 06:49, Vladimir Shipovalov wrote:

On Friday, October 10, 2014 1:21:17 AM UTC+4, joanna wrote:

Aren't you bothered by having closed source BIOS? And what about your 
processor? ;) 

I am more bothered by the fact that modern Intel CPUs contain a secret radio chip ( Intel anti-theft 3.0 technology )

which could allow to remotely disable, or erase the data, from any modern Intel-based computer.

Intel CEO have dodged the NSA-related questions during the interview for a reason...

Interesting. Can you send a link to the interview?

Unfortunately, judging by Hardware Compatibility List of Qubes OS,

it looks like that Qubes OS is mostly aimed on Intel-based computers rather than AMD

:-(

This might not be the case if AMD had some mobile chips that support IOMMU (I have not seen any on the market). Most of us strongly prefer to use laptops.

Also, System Requirements page tells that:

1) Intel integrated GPUs are strongly preferred

2) There could be compatibility problems with NVidia GPUs

3) AMD GPUs haven't been tested at all

Lately there have been reports of Nvidia and AMD graphics working just fine with Qubes. So I believe that preference is going away.

AMD hardware has the worst support by Qubes OS - but, because of the mentioned problems with Intel,

that wouldn't prevent me from purchasing MSI laptop that is based on FX-7600P - best AMD APU for notebooks.

This laptop has both AMD integrated (Radeon R7) and discrete (Radeon R9 M290X) graphics.

Of course I will have problems with that pair, but maybe I could improve Qubes OS support for this hardware...

Had some development experience with Linux kernel modules in the past

about BIOS: although there are some coreboot-based laptops, they are very old and impossible to find for sale.

That is a major problem with coreboot project: by the time the support for specific hardware is introduced and perfected,

it is already "End-Of-Life". For example, HP Pavilion m6 1035dx (latest AMD-based laptop that is supported by coreboot)

is 2 years old and has mediocre performance

I don't think Qubes will ever put a strong focus on performance. Security is more important.

[Vladimir Shipovalov]

On Saturday, October 11, 2014 12:10:01 AM UTC+4, cprise wrote:

On 10/10/14 06:49, Vladimir Shipovalov wrote:

On Friday, October 10, 2014 1:21:17 AM UTC+4, joanna wrote:

Aren't you bothered by having closed source BIOS? And what about your 
processor? ;) 

I am more bothered by the fact that modern Intel CPUs contain a secret radio chip ( Intel anti-theft 3.0 technology )

which could allow to remotely disable, or erase the data, from any modern Intel-based computer.

Intel CEO have dodged the NSA-related questions during the interview for a reason...

Interesting. Can you send a link to the interview?

http://www.reddit.com/r/IAmA/comments/1ycs5l/hi_reddit_im_brian_krzanich_ceo_of_intel_ask_me

Short summary :

Like many other famous people, Intel CEO came to Reddit and arranged an interview with redditors.

However, he intentionally ignored all the NSA-related questions, despite they had the highest amount of upvotes!

Several days later (he probably took some time for consulting) Intel CEO wrote just one comment regarding NSA

using a very careful wording, that could be interpreted in many senses.

http://www.reddit.com/r/privacy/comments/1yma58/intel_ceo_dodges_nsa_questions_in_reddit_ama/

People have asked him several times to clarify his wording, to clear the doubts. But he just left and never returned...

All that, in addition to Edward Snowden's revelations, made me think that Intel has something to hide...

That is why I am looking for an alternative, such as AMD (or Loongson maybe?)

On Saturday, October 11, 2014 12:10:01 AM UTC+4, cprise wrote:

Unfortunately, judging by Hardware Compatibility List of Qubes OS,

it looks like that Qubes OS is mostly aimed on Intel-based computers rather than AMD

:-(

This might not be the case if AMD had some mobile chips that support IOMMU (I have not seen any on the market). Most of us strongly prefer to use laptops.

I found a note on this page - https://groups.google.com/forum/#!msg/qubes-users/Sz0Nuhi4N0o/ZtpJdoc0OY8J

it seems that IOMMU support mostly depends on the manufacturer of AMD laptop (if they have decided to implement this feature)

===

Thank you for good news about AMD graphic cards working :-)

Security is the top priority, but it would be nice to have a good performance too)

[Joanna Rutkowska]

I'm sorry, but I fail to see any reason why AMD should be any better
than Intel with regards to (hypothetical) NSA cooperation/backdoor
introduction?

joanna.

> On Saturday, October 11, 2014 12:10:01 AM UTC+4, cprise wrote:
>>
>> Unfortunately, judging by Hardware Compatibility List

>> <https://qubes-os.org/wiki/HCL> of Qubes OS,

[Vladimir Shipovalov]

I understand that all the major USA-based consumer high technology companies have to cooperate with NSA.
And of course, that includes AMD. For example: according to this article, there was a suspicious backdoor at AMD graphic drivers:

http://www.phoronix.com/scan.php?page=news_item&px=MTU2OTc

However, unlike the story with Intel, there's no any hardware related evidence regarding AMD-NSA cooperation.
That gives me an impression that it could be software-only cooperation, although I can be very wrong here...

[Zrubi]

On 10/12/14 14:13, Vladimir Shipovalov wrote:
> However, unlike the story with Intel, there's no any hardware related
> evidence regarding AMD-NSA cooperation.
> That gives me an impression that it could be software-only cooperation,
> although I can be very wrong here...

Or maybe that one is just better covered and lower the hype around ;)




--
Zrubi

[Davíð Steinn Geirsson]

On Fri, 10 Oct 2014 03:49:39 -0700 (PDT)
Vladimir Shipovalov <quickcr...@gmail.com> wrote:

> On Friday, October 10, 2014 1:21:17 AM UTC+4, joanna wrote:
> >
> >
> > Aren't you bothered by having closed source BIOS? And what about
> > your processor? ;)
> >
>
> I am more bothered by the fact that modern Intel CPUs contain a
> secret radio chip ( Intel anti-theft 3.0 technology )
> which could allow to remotely disable, or erase the data, from any
> modern Intel-based computer.

Do you have a credible source for the hidden radio functionality in
intel chips? I've heard it before but dismissed it as nonsense, and I'm
still very skeptical of it.

If they were including such a feature, I would expect them to
prominently advertise it in the anti-theft whitepapers. After all, it's
marketed at IT departments looking to combat equipment theft, and I'd
expect them to be all over that feature. And besides, if they were
incurring the costs of including a whole 3G modem on-die, why would
they not let the user access that feature? It'd sell more units, and
the OEMs would not have to include a seperate 3G modem. It just makes
very little business sense.

I doubt you could put the a GSM/3G antenna on-die as well, so the
motherboard manufacturer would likely need to have an on-PCB antenna at
least. And then you'd expect the radio pins to be on the CPU
datasheets. Both of which would be quite visible, and I would expect
someone to have pointed it out by now. Instead, searching for this just
brings up really dubious, unsupported claims with circular citations.
Some of them link to news articles about the AT technology that really
don't support the claim of on-die 3G modems at all, just vague claims
about being able to wipe/shutdown over 3G, which seems more
likely to mean using the mini-PCIe 3G modems that many laptops have.

I have not studied intel AT technology in detail, please correct me if
I am wrong.

> Intel CEO have dodged the NSA-related questions during the interview
> for a reason...
>
> Unfortunately, judging by Hardware Compatibility List

> <https://qubes-os.org/wiki/HCL> of Qubes OS,

> it looks like that Qubes OS is mostly aimed on Intel-based computers
> rather than AMD
> :-(
>
> Also, System Requirements page

> <https://qubes-os.org/wiki/SystemRequirements> tells that:

> 1) Intel integrated GPUs are strongly preferred
> 2) There could be compatibility problems with NVidia GPUs
> 3) AMD GPUs haven't been tested at all
>
> AMD hardware has the worst support by Qubes OS - but, because of the
> mentioned problems with Intel,
> that wouldn't prevent me from purchasing MSI laptop

> <http://hardforum.com/showpost.php?s=32339d5e812bc2abd5cbd42cabffb5bf&p=1041102732&postcount=6>

> that is based on FX-7600P - best AMD APU for notebooks.
> This laptop has both AMD integrated (Radeon R7) and discrete (Radeon
> R9 M290X) graphics.
> Of course I will have problems with that pair, but maybe I could
> improve Qubes OS support for this hardware...
> Had some development experience with Linux kernel modules in the past
>
> about BIOS: although there are some coreboot-based laptops, they are
> very old and impossible to find for sale.
> That is a major problem with coreboot project: by the time the
> support for specific hardware is introduced and perfected,
> it is already "End-Of-Life". For example, HP Pavilion m6 1035dx
> (latest AMD-based laptop that is supported by coreboot)
> is 2 years old and has mediocre performance
>

Indeed, I would really love a modern coreboot-supported
(well-supported, including S3 sleep and such) laptop with working DRTM
and IOMMU. A man can dream, I guess.

[BM-2cTjsegDfZQNGQW...@bitmessage.ch]

I wish the series of my new laptop (x750j and like models) didn't have
this technology, though the user manual explicitly details the 3g chip
and "anti-theft" technology, and how it can be used to access the hard
drive remotely when the computer is "stolen". The antitheft can
aparently be turned off in the bios where it is listed, which I did,
though surely that would be trival to circumvent on intel's side.
Intel's website also describes the 3g chips functionality shamelessly.
I bought the laptop because it had vt-x and vt-d for qubes...I think it
at least relies on a windows app for reasonable function, though of
course there isn't any absolute technological requirement why this must
be the case.

[Radoslaw Szkodzinski]

On Mon, Oct 13, 2014 at 12:30 AM,
<BM-2cTjsegDfZQNGQW...@bitmessage.ch> wrote:
> I wish the series of my new laptop (x750j and like models) didn't have
> this technology, though the user manual explicitly details the 3g chip
> and "anti-theft" technology, and how it can be used to access the hard
> drive remotely when the computer is "stolen".

Unfortunately, all laptops with TPM known to me are also equipped with
this backdoor.
(or Intel Remote Management Technology, which is equivalent)

> The antitheft can
> aparently be turned off in the bios where it is listed, which I did,
> though surely that would be trival to circumvent on intel's side.

Not just Intel then. Toggling it should be only possible locally after
additional authentication, but we cannot be certain - the firmware is
not open.
Similarly we cannot be sure Intel didn't put any backdoor in the
static root of trust functionality to specifically allow some kinds of
compromising hardware.
Someone would have to reverse-engineer it and see...

--
Radosław Szkodziński

[Ph.T]

On Thursday, October 9, 2014 12:10:39 PM UTC-7, Vladimir Shipovalov wrote:

( I hope that Qubes OS is 100% free and open source, without closed-source blobs,

like these operating systems endorsed by FSF: http://www.gnu.org/distros/free-distros.html )

Chrome OS offers an x86 machine with mostly open firmware;

I wondered if we could fork Xen for a Chromebook .

. the Chromebook Pixel may support VT-d

https://plus.google.com/+RussellHolly/posts/Y8gsapo8Sy1

https://plus.google.com/+PhilipTorrance/posts/KFqiJjUJN5f

see pro's and con's of Pixel .

http://wiki.gentoo.org/wiki/Google_Chromebook_Pixel_LTE

lwn.net`Nathan Willis 2013.2:

http://lwn.net/Articles/537791/

At linux.conf.au, Google's Duncan Laurie 

presented a talk (slides) about the company's 

recent work writing open source firmware 

for its Chrome OS-based laptops. 

. there are still some instances of closed firmware

on the current [2013] crop of Chrome OS devices.

Coreboot executes some closed-source binaries, 

the first of which is the Intel reference code binary

required to get memory up and running. 

This code is provided by Intel

to licensed BIOS vendors. 

see Intel Firmware Support Package.

http://www.intel.com/content/www/us/en/intelligent-systems/intel-firmware-support-package/intel-fsp-overview.html

Another blob of closed code provided by Intel

is the firmware for the Management Engine, 

a microcontroller handling various features 

like clock signal generation. 

Laurie said the Management Engine makes life more difficult for Chrome OS,

since it is quite large (from 1.5 to 5 MB) 

and difficult to configure and debug. 

Configuration of the blob is mandatory, 

and can only be done with an application Intel provides

for Windows machines only.

Chrome OS does need video capabilities for

recovery mode and developer mode, 

so the project currently includes 

the Intel-provided binary blob for this purpose.

The Embedded Controller (EC) is found in virtually all notebooks, 

and is a tempting (if largely unknown) security target,

so Chrome OS has incorporated it into its verified boot process.

The code is open .

 

[Vladimir Shipovalov]

According to Snowden's files, there is a strong connection between Google and NSA.

I could bet my money on that there's some sort of backdoor in a closed part of firmware,

or that there's a security hole in the open part of it, which was created on purpose.

Moreover, Chrome OS is aimed to be used together with all those Google services...

[Ph.T]

On Wed, Oct 22, 2014 at 3:41 AM, Vladimir Shipovalov <quickcr...@gmail.com> wrote:

On Sunday, October 19, 2014 2:45:54 AM UTC+4, Ph.T wrote:

On Thursday, October 9, 2014 12:10:39 PM UTC-7, Vladimir Shipovalov wrote:

( I hope that Qubes OS is 100% free and open source, without closed-source blobs,

like these operating systems endorsed by FSF: http://www.gnu.org/distros/free-distros.html )

Chrome OS offers an x86 machine with mostly open firmware;

I wondered if we could fork Xen for a Chromebook .

. the Chromebook Pixel may support VT-d 

According to Snowden's files, there is a strong connection between Google and NSA.

I could bet my money on that there's some sort of backdoor in a closed part of firmware,

or that there's a security hole in the open part of it, which was created on purpose.

Moreover, Chrome OS is aimed to be used together with all those Google services...

I don't know how Snowden singles out Google;

every corporation that hasn't folded

has a strong connection with NSA .

. every box has a backdoor in a closed part of firmware;

but Google has more open firmware,

and that should interest us if it can boot Xen .

[Andrew B]

On 10/23/14 06:32, Ph.T wrote:

> On Wed, Oct 22, 2014 at 3:41 AM, Vladimir Shipovalov <quickcr...@gmail.com <mailto:quickcr...@gmail.com>> wrote:
>
> On Sunday, October 19, 2014 2:45:54 AM UTC+4, Ph.T wrote:
>
> On Thursday, October 9, 2014 12:10:39 PM UTC-7, Vladimir Shipovalov wrote:
>
> ( I hope that Qubes OS is 100% free and open source, without closed-source blobs,

> like these operating systems endorsed by FSF: http://www.gnu.org/__distros/free-distros.html )
> <http://www.gnu.org/distros/free-distros.html>

>
>
> Chrome OS offers an x86 machine with mostly open firmware;
> I wondered if we could fork Xen for a Chromebook .
> . the Chromebook Pixel may support VT-d
>
>
> According to Snowden's files, there is a strong connection between Google and NSA.
> I could bet my money on that there's some sort of backdoor in a closed part of firmware,
> or that there's a security hole in the open part of it, which was created on purpose.
> Moreover, Chrome OS is aimed to be used together with all those Google services...
>
> I don't know how Snowden singles out Google;
> every corporation that hasn't folded
> has a strong connection with NSA .
> . every box has a backdoor in a closed part of firmware;
> but Google has more open firmware,
> and that should interest us if it can boot Xen .
>

> --
> 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...@googlegroups.com <mailto:qubes-devel...@googlegroups.com>.
> To post to this group, send email to qubes...@googlegroups.com <mailto:qubes...@googlegroups.com>.
> Visit this group at http://groups.google.com/group/qubes-devel.
> For more options, visit https://groups.google.com/d/optout.

I am quite sure x86 Chromebooks can boot Xen. I run Qubes on an HP Chromebook 14. It doesn't have VT-d, but VT-x works just fine.
As repeatedly stated, even "more free" Coreboot loads non-free ME firmware. Perhaps this is what you meant when you said, "every box has a backdoor in a closed part of firmware"?

Andrew