So yeah does Qubes meet the Free System Distribution Guidelines or is it (easily) possible to swap out the proprietary blobs for free alternatives?
@tivalivupo, please have a look at the FAQ.
thanks, so it’s basically free as long one doesn’t install anything nonfree?
1 Like
no not free, as long as you dont remove firmware packages used in fedora template for networking for example, maybe debian has firmware packages too. and its not goal or intention of qubes to reach FLOSS. if this important to you, i guess you have to build your own templates without firmware.
I would like to see a list of commands, which would make Qubes fully free. I mean something like:
in Fedora template:
sudo dnf remove firmware-nonfree-*
in Debian template:
Remove contrib and non-free repositories from /etc/apt/sources.list
in dom0:
?
i guess you have to script that on your own.
vrms tells me that dom0 is fine - except for some Apache Licensed code,
and Qubes package which is GPL2.
debian-11 has non-free firmware packages, but Debian wont pass muster as
free distro, because it includes the contrib and non-free repos. You
can use another template in its place which would be FSF endorsed.
But, and this is a huge but, Qubes will not be free software
because it is a security OS. At present, this means that it has to use
microcode which is non-free.
The free distributions don’t use microcode, which means that they are wide
open in security terms - the libre kernels even removed the warnings
about this so that users would not be tempted to install non-free
software.
4 Likes
I don’t quite understand what you’re saying? Is only proprietary software secure, like, security by obscurity? Or why can’t free software be secure?
@tivalivupo, @unman is talking about Spectre/Meltdown and similar speculative execution issues with modern CPU. Those vulnerabilities can be partly worked around by disabling specific features, but some of it can only be effectively mitigated by updating the microcode running in the CPU.
These updates are proprietary and not available in source code. So you can decide whether you want to apply the microcode updates to mitigate the security issue, or run entirely free software but remain vulnerable. Since the entire point of Qubes OS is compartmentalization, not applying these updates is not an option.
But I have heard there are backdoors in proprietary software for the glowies to come in. I don’t want glowing people to access my computer. It should only compute the things I want. Are there no modern CPUs that do not have big security flaws or with the ability to mitigate them with free software? That proprietary microcode might just open up another backdoor or security flaw by “fixing” Spectre/Meltdown, doesn’t it?
Thank you @unman
So, to get a free system, one should remove the contrib and non-free repos in Debian, as I mentioned above. Sounds fine to me. Will Qubes functionality not suffer from this? Will some packages have to be removed? I would like to do this and, ideally, it could be mentioned in the documentation.
Microcode is an important exception, which any reasonable person should accept, because it fixes a clear vulnerability. Any modern CPU cannot be fully free anyway.
You probably heard it about Intel ME.
For modern CPUs, maximally, you can disable and (sometimes) neutralize Intel ME. It will still contain some proprietary bits, including the microcode, but much fewer.
Yes, it can. But we know for sure that without the update, the backdoor is open…
1 Like
i don’t think so
just all x86, most arm cpu and more
backdoors in proprietary software
As @fsflover pointed out you most likely heard/read about the Intel Management Engine (ME), which you can minimize/disable. In addition you can replace the BIOS of your board with free software like coreboot/heads to establish a root of trust. I highly recommend you look into this. A ThinkPad X230 or T430 is probably the best choice at this time. Or if you got lots of money you could by a Privacy Beast / NitroPad / Librem.
proprietary microcode might just open up another backdoor or security flaw by “fixing” Spectre/Meltdown, doesn’t it?
Highly unlikely due to the scrutiny these updates and their functionality receive from security researchers worldwide competing to find the next Intel/AMD flaw. If you wanted to place a backdoor you wouldn’t choose the spot receiving the most scrutiny. That’s no guarantee of course and they might introduce another flaw by accident too.
Until we have a Qubes OS that runs on fully free and auditable hardware, this is as good as it gets. There are efforts underway, but it’s hard to say how long it will take until they become reality. I’ve made my piece with the fact that I’ll rock my Ivy Bridge T430’s until then and are extremely thankful to all the heroes making coreboot / me_cleaner / heads and obviously Qubes OS and the various Linux distributions available to us. It can really restore you faith in humanity to see this. Just maybe we as a species will figure out how to cooperate like this in other parts of our life too.
2 Likes
A bit off-topic in this thread, but I would like to ask:
After using me_cleaner tool to clean up the intel ME and installing Coreboot to an X220 machine, do the remaining “proprietary bits” get executed during machine operation, or do they just stay in the firmware as non-executed bits?
I think what I am asking is, whether the remaining proprietary bits continue to function after me_cleaner + coreboot.
it is executed, if it non-executed bits, why they can’t just remove it
I am not well-educated in this topic, however, my intuition would be due to checking the hash of the proprietary bits and contrasting that with some signed value hardcoded to the CPU or whatever–that would make these bits unable to be removed even though they weren’t being executed actively.
so …
more info here
I skimmed through that, I know.
However, reading something once isn’t same as “understanding” it. That’s why I brought that up in order to consult opinions of others.
Thanks for the answers everyone, I think I understand the situation now. I guess I’ll get a X230/T430
I would like to add to this that you simply cannot run without microcode, it is always there even if a distribution does not include it, as it is baked into the CPU. Microcode included in distributions is only a newer version. So imho not including microcode into a distrubution is only a false sense of freedom(with the lack of a better word) and leaves you open to side channel attacks.
1 Like