Running an x86 system without microcode updates is foolish. Projects like Libreboot and Trisquel that support x86 but do not include the needed microcode updates are fundamentally insecure and misguided. x86 is a fundamentally closed platform and will always require non-free microcode at a minimum. If you want to run Qubes OS on a fully-free system, the best way to get that is to help with the port of Xen to POWER, as POWER can be secure without non-free firmware.
1 Like
Most of this thread is not actually about microcode, but firmware for various auxiliary devices (wifi etc). Those are totally independent of CPU architecture you use.
You can attempt to build your system with devices running only open-source firmware. If you want to achieve it in full, you’ll indeed probably need POWER CPU (disclaimer: I haven’t checked microcode situation there, but it is possible it’s better than on Intel/AMD). But it is very easy to get into a trap of old (proprietary or not) firmware. If you get a device that appears to work fine without loading any firmware blob, it simply runs a firmware stored on the device itself. It could be an open source firmware, sure, but in fact, you have very little ways of verifying that claim (you’d need a trustworthy way of extracting the firmware, and a reproducible build to compare against). In some cases this embedded firmware can in fact be updated (devices with writable firmware flash), but has its own set of issues (you loose reliable way to reset device to a “clean” state).
Ideally you want auxiliary devices without mutable internal storage and all the firmware must be loaded when device is initialized. And that firmware you want to be free and open source and can be built by anyone.
In practice, many attempts at “blob-free” devices in fact fall into some of those categories:
- embedded non-updateable proprietary firmware; if that firmware is bug-free, then great, but we all know such thing doesn’t exist, so you are forced to replace the whole device to get patches (if you are lucky enough to find one that actually exists)
- embedded (old) proprietary firmware, that is used if OS doesn’t load newer one; here, rules for “blob-free” system prevents you from shipping such update, so while in theory it’s slightly better for user security than previous point, in eyes of FSF it is worse
- embedded updatable proprietary firmware; here device has mutable firmware storage, that can be updated - if you load the update, it will run it later too; the downside is you loose some of the control what firmware device actually runs, because if your system become compromised once, the firmware can be replaced with malicious one (including modification to refuse further updates). This is BTW a model that BIOS rootkits use - trendy topic recently, but those exist for decades already.
Note FSF recommends option 1 (if no free firmware is available), which is actively harmful for users overall security, but also their freedom (no way to replace proprietary firmware with free alternative, when one become available).
3 Likes
I don’t really know anything about the Debian template situation except what I’ve seen folks say in this thread (and have hitherto avoided discussing it for that reason). Let’s ask @marmarek:
I’ve already dealt with these more than a week ago.
Yes, we do.
We do it for security, and to make the experience easier for a wide
range of users on install. (I specifically added a wider range of
firmware packages to the Debian template to match those available on Fedora)
It’s not an exception to our policy. It’s a standard application of it.
“We try to respect each distro’s culture, where possible”
That description is inaccurate and should be changed.
The software is free. The OS is not.
(This has nothing to do with Debian in particular.)
" All the software produced by Qubes is free.
Because we are a security distribution we include non-free firmware to
address known vulnerabilities.
Because we want to make installation easier for a wide range of users
across many devices we include some non-free firmware and drivers in our
standard templates."
As Qubes is libre, it’s open to anyone to produce a version of the OS that is
fully free. I don’t know what the point would be, but they could. It just
would not be a security distribution - perhaps “Libre Qubes - a
definitely insecure Operating System”
I’ve previously offered a Trisquel template, and will undoubtedly do so again.
I wish that a quarter of the energy expended on this thread was put in to
improving Qubes.
When I comment in the Forum or in the mailing lists I speak for myself.
1 Like
That is the YubiKey situation. They do have a decent security policy, and will replace devices found to have security flaws.
Yes.
Is the non-free firmware included in this “compilation”? AFAIK yes. If yes, you can’t reasonably say the following
You can’t distribute proprietary software under GPLv2. (Some) users are mislead into thinking that Qubes .iso contains no proprietary software.
I think it’s pretty clear what that means. Fedora create free software, but distribute it together with non-free software (firmware) which they do not create. It’s a very careful and correct wording, unlike with Qubes OS.
Fedora do not try to call their software compilation (i.e. .iso files) “free software”, which it isn’t. It’s a compilation of free and non-free software, just like Qubes. It’s a fact based on the licenses of the software, not purity. This is indeed unfortunately unavoidable today, but clearly explaining it to the users is nevertheless important.
I guess if you wrote “Qubes project creates free software”, it would be at least technically correct. But the operating system as a whole is not free software. Alternatively, as I also suggested above, one could say that Qubes OS is free software, except the CPU microcode and default operating system(s) running inside in VMs (is this short enough?).
Agree. I’m just trying to point out technical/naming inconsistencies in the description, which mislead the users.
I believe FSF will not go against replacing the proprietary firmware with free software, if the latter becomes available. Freeing software is actually the only good reason to use non-free software, according to the FSF.
Not everyone has an ability to do so. Also, fixing incorrect description of the project is improving Qubes.
My arguments about Debian were ignored for some reason. Why can’t Qubes ship actual, official Debian in the default configuration? How does it improve security? How does it improve user experience? It doesn’t. It goes against the expectations of Debian users. The docs don’t even tell how to achieve the official Debian configuration. I was mislead by this.
Imagine that there is some Xen vulnerability, which requires a carefully written exploit that is easy to spot. You set up some scanner to watch for it (defense in depth). Maybe you can even watch from outside the qube? Proprietary firmware can easily hide such exploit and regularly ship updates to it, so any tiny malicious code in the qube can use it and escape.
I already replied to this above:
I don’t think anybody disputed this.
I understand for functionality … but could you clarify the security argument?
Here is the non-free software in a clean debian template:
$ vrms
Non-free packages installed on debian-11-vrms
amd64-microcode Processor microcode firmware for AMD CPUs
firmware-amd-graphics Binary firmware for AMD/ATI graphics chips
firmware-linux Binary firmware for various drivers in the Linux kerne
firmware-linux-nonfree Binary firmware for various drivers in the Linux kerne
firmware-misc-nonfree Binary firmware for various drivers in the Linux kerne
intel-microcode Processor microcode firmware for Intel CPUs
Contrib packages installed on debian-11-vrms
iucode-tool Intel processor microcode tool
6 non-free packages, 0.5% of 1322 installed packages.
1 contrib packages, 0.1% of 1322 installed packages.
I don’t see a security argument, but do see a functionality argument, for some firmware. (Is a VM even allowed to load microcode into the CPU? Do gpu firmware provide any functionality? If you are somehow getting GPU passthrough working, I think it is not too much to ask to apt-get the GPU firmware).
But the exclusion of this software is why some users chose debian in the first place!
where possible, not where convenient.
It is possible to have both debian template without non-free, and working wifi etc… (even if it requires non-free firmware): just use fedora for sys-*. That is the default set up by the qubes installer when a user selects both fedora and debian templates in the system installer - the service VMs default to fedora-based.
I agree removing non-free from debian is a major inconvenience for people who deliberately have no fedora template at all (by deselecting the fedora template during installation). But the kind of person who wants a debian-template-only system is more likely to have strong opinions about free software, more accepting of breakage caused by their choices, and more likely have hardware specifically chosen to work with debian, than the average qubes user.
1 Like
I’ve opened a PR that attempts to address some of the matters discussed here. Feedback is welcome:
In particular, it adds a sentence to the license page that attempts to address the matter of non-free firmware being included in the compilation of software that is Qubes OS, but I don’t know to what extent it is helpful or makes sense (see my comment here).
The bulk of the PR is a new description for the “What is Qubes OS?” entry and a new entry titled “Is Qubes OS free and open-source software?”
(While writing this, it occurred to me that the debate over whether Qubes can be called “free” may also apply to whether Qubes can be called “open-source,” i.e., whether the inclusion of some non-open-source software disqualifies it from being called “an open-source operating system.”)
1 Like
Also added this change:
In general, we try to respect each distro’s culture, but we reserve the right to make modifications that we deem appropriate.
Some folks started to get very legalistic about parsing the precise language of “where possible” as opposed to “where convenient,” etc., which seems entirely misplaced, as that language was never in the context of a binding contract, legal license, or similar document. Rather, it was in the context of an informal FAQ entry, and was therefore not written with that degree of precision in mind. Moreover, “where possible” is usually (as it is here) a figurative turn of phrase used to mean something like “to the extent feasible” or “as a high priority (but not necessarily the highest and still as just one priority among others),” similar to saying that I will do something “as much as I can,” which usually does not literally mean until I physically collapse from exhaustion, malnutrition, organ failure, etc.
adw, I just read your latest commit and I think it’s excellent. I personally like that much better than the previous phrasing before your modification today, as I think it is far clearer for people who care to know more exactly what they might be using (such as myself). Like many of us, I imagine, I knew what what Qubes was fairly well and valued its work and existence without the explicit definition when I first downloaded it, but I do see the value of, and indeed I respect, that level of clarity in the modern software landscape.
One suggestion: I think it would make a lot of sense to hyperlink or cite the free/libre words you have there to the FSF definition page and perhaps cite any other terms or definitions that might be contentious? That way everyone would be very clear and the definition concerns would then be relegated to the FSF or other defining-organization.
1 Like
Doesn’t this weaken the statement to the point that it is vacuous?
Just in everyday language, there is a difference between the two.
If this is with reference to the specific case of removing non-free firmware from debian, a still fully-functional default (with fedora-based sys-net) is not that high a price to pay.
1 Like
I just thought of another thing I’d really like to see added to the documentation aside from my citation suggestion above: Can we compile the list of binary firmware or microcode or any other closed source material and link from your statement on the non-free components to that page? On the non-free manifest, we could include exactly what files are involved and exactly what they do and why they are there, as well as which Templates or VMs they are contained in, a bit like an ingredient list on one of the more enironmentally-responsible cleaning products that I have started to see recently! I would value that and I bet some other out there would as well.
1 Like
Before you decide to weaken this policy, I think it is worth looking into the motivation for the policy. Maybe someone can chime in with the actual historical reasons for this policy, but here is why I think a template respecting a distro’s culture is a good idea, especially in regards to software inclusion:
- Respect for user choice. It respects the user’s choice of template, if it is for culture reasons.
- Informed consent to licenses. When users install a template, they agree to be bound by the licenses of the software in the template. Users should not reasonably be expected to provide informed consent to be bound to licenses that they do not expect to find in the template, given upstream’s inclusion policy.
- Trademark dilution. If the name of a distro is used to describe a template without qualification, it should not differ from that distro in an essential aspect. (For debian, that essential aspect is freedom). (How would you feel if a vendor sells laptops preinstalled with Qubes stripped of all proprietary software, and they call it Qubes? That is not nice, because it differs from Qubes in an essential aspect - its security - and misleads users).
- Upstream docs. Unnecessary changes can conflict with the upstream documentation.
2 Likes
Sure, done. I didn’t really see any other contentious terms or definitions, but let me know if you do.
No. It still communicates exactly what it says. We get a lot of people asking us to make tons of changes (basically, “build me my wish-list Linux distro as a template”). Being able to point them to this FAQ entry is handy. It discourages people from asking us for every conceivable Fedora and Debian change that would be nice to have (in their mind). It also has other benefits, as explained in the entry itself.
Also, giving the devs more latitude to do what’s best for users and the project is a boon. Weakening the statement is a feature, not a bug.
Did you actually read the whole thing? The answer is already right there in the entry. Here’s the entire entry, as it stands right now:
What is Qubes’ attitude toward changing guest distros?
We try to respect each distro’s culture, where possible. See the discussion on issue #1014 for an example.
The policy is there mostly to ease maintenance, on several levels:
- Less modifications means easier migration to new upstream distribution releases.
- The upstream documentation matches the distribution running in the Qubes VM.
- We’re less likely to introduce Qubes-specific issues.
- Each officially supported distribution (ideally) should offer the same set of Qubes-specific features - a change in one supported distribution should be followed also in others, including new future distributions.
Notice the bolded portion. The main motivation is to ease maintenance. In other words: convenience! So it makes no sense to criticize the interpretation of “where possible” as “where convenient,” since that is already part of the explanation to begin with.
Now I’m guessing you’ll say, “Yeah, but convenience for maintainers isn’t the same thing as convenience for users!”
You’re missing the point. All that means is that nobody has gotten around to adding stuff about convenience for users to this FAQ entry yet. This is not a binding legal document! Not even close! You are trying to turn it into something it’s not. It’s here to explain our rationale for why we operate the way we do, not to bind us to operating in a specific way.
1 Like
I think I’d like to try to create that in documentation, as suggested in the PR page you link, adw. I haven’t ever used the github system before to contribute something so it may take a bit of time to get familiar for me, but the big obstacle for this addition is that I am not yet linux-savvy enough (working on it) to know how to find out what binaries or other proprietary code might be included in each template or Qubes base. Can anyone point me to how I might determine that?
1 Like
I’m sorry, I should have kept the rest of the section in mind as I made my posts.
So combining the list in the FAQ I missed with mine, gives the following as reasons for respecting upstream distro’s culture:
- FAQ1. Less modifications means easier migration to new upstream distribution releases.
- FAQ2. The upstream documentation matches the distribution running in the Qubes VM.
- FAQ3. We’re less likely to introduce Qubes-specific issues.
- FAQ4. Each officially supported distribution (ideally) should offer the same set of Qubes-specific features - a change in one supported distribution should be followed also in others, including new future distributions.
- Respect for user choice. It respects the user’s choice of template, if it is for culture reasons.
- Informed consent to licenses. When users install a template, they agree to be bound by the licenses of the software in the template. Users should not reasonably be expected to provide informed consent to be bound to licenses that they do not expect to find in the template, given upstream’s inclusion policy.
- Trademark dilution. If the name of a distro is used to describe a template without qualification, it should not differ from that distro in an essential aspect. (For debian, that essential aspect is freedom). (How would you feel if a vendor sells laptops preinstalled with Qubes stripped of all proprietary software, and they call it Qubes? That is not nice, because it differs from Qubes in an essential aspect - its security - and misleads users).
1 Like
Me pointing something out that was already discussed.
What you just did there is asking someone to spend a lot of time and energy compiling a list, publishing it and keeping it up to date!
Looking at just the work done by an incredibly small team for all of us that I even see (and I am sure there is tons more that I don’t see), I cannot help but see this as either rude and/or thoughtless. I know you very likely didn’t mean it that way, but that’s how it could be perceived.
If you do, then you should spearhead an effort to compile that list and commit to keeping it up-to-date. If you don’t have the know-how to do so, then find others that care as much as you do and sign them up. Because otherwise you just asked people who spend their energy giving you a free and reasonably secure OS to take a meaningful amount of that time and attention to compile that precious list of yours instead of working on the OS you use every day.
Me pointing something out that was already discussed.
Have you even bothered to look at the FAQ entry and followed the link to the respective issue and it’s discussion?
My apologies @moonlitOrca I read your answer offering to author said list after firing off my moody reply.
Sven, Thanks for letting me know how that can be perceived. I had not thought that my idea might bother anyone, and I certainly hope I didn’t make you or adw or anyone else working on this project feel unappreciated. Because you are all very appreciated, more than I can reasonably convey on a forum with no face-to-face interaction for social cues, and I try to make that clear when I can. I have personally seen some of the work you, unman, adw, and fslover have done in helping other newbies like me to do…stuff, constantly. I love that. I find people, like you, who are willing to happily assist others to do something over and over and over again to be impressive and I respect that. It’s part of what I do in my normal life as a teacher as well, because I think it matters. The team who program and script and build Qubes I find just as impressive; I am using this Operating system honestly, not because it is convenient for me nor because I feel I need it for my life, but in order to support that vision and to help further it in any way that I can as I go forward, because I think every new Qubes user helps to move the project (and open source software in general) forward just by learning, contributing, spreading awareness, and even just simply being a user who asks for things and becomes part of the base the developers build for.
Now, as for the documentation idea: I am incredibly new to Qubes…like just started using it daily 1 week ago, though I have been suffering through getting all my hardware working on and off for months to use it, and gain enough familiarity to feel comfortable that I won’t be left hanging with a dead computer by traveling with my Qubes laptop. So I haven’t seen anywhere near what you have seen of this project and its work over time. It might be that many people come on here and ungratefully cause grief or disrespect the other members of the community, or that most people never choose to contribute much beyond just being an active user. I haven’t seen enough yet to know. But I do know that with this idea, I am happy to spearhead it and in fact, that was my intention which is why I chose to use the pronouns “we” when I stated my original idea, because I do want to help build that documentation. I was quite happy when adw linked me to a page on how to make contributions, because I am really quite a skilled writer and would like to help add to the project that way. I have read a lot of the documentation myself already as I have tried to get my system set up the way I want, and I really like the style the documentation is written in: its some of the clearest and most well-constructed documentation that I have seen on a project. It’s certainly not complete enough yet, but what is there is generally great.
I’m also, probably like most people on here, an intelligent and very technically savvy human being or I wouldn’t be even attempting to and successfully using qubes daily. But I am very new to Linux in general and I don’t yet know how to figure out what packages or libraries are proprietary, so I may need some help in that direction before I can write up documentation on it. Probably the most appropriate thing to do is for me to make a new post on the forum asking for help to determine the proprietary packages, and then see if I can get some experienced linux users to help me with that. But any other suggestions are welcome. And I will certainly continue to build more documentation once I have that done too, as that has always been my goal with working in Qubes; in fact, my first project I had planned was to do a big write up in the HCL reports for the Framework Laptop once I got it all working, both here and on the Framework site (I almost have gotten everything set, but the AX210 card is killing me…something about the Virtualization layer). I may have to go forward with that without getting the wifi figured out after all.
So I will help build this out, but I do want to say, as well, that even if I or anyone else is asking for a thing without the intention to do it myself or themselves, I don’t consider that disrespectful or destructive in any way! I think that has its own value because it shows what other homo sapiens participating in or using the project are interested in achieving, and after all the OS is being built by a small group of homo sapiens to benefit themselves and the larger group too. Naturally, not everything can be accomplished or built by a small group (or even a large group), so if a request is made or an idea put forth that takes too many resources, I expect and understand that it will be ignored or tabled for another time, and that’s OK. I believe that an idea and an input is still valuable in many ways even if it never becomes what the thinker had hoped for. And certainly no disrespect or obligation is ever intended by me in my thinking or posting. I very much appreciate you all, even if all you’re doing is posting opinions or ideas, but especially if you are contributing as many of you are whom I recognize!
2 Likes
Thank you for that constructive reply @moonlitOrca. I regretted the tone of my post almost instantly and are glad you are taking it the right way. I’ll try to moderate myself.
2 Likes