HWE kernels can load proprietary kernel modules
- Anmelden oder Registrieren um Kommentare zu schreiben
Title pretty much sums it up. Linux-libre shouldn't be able to load proprietary modules, yet the HWE kernels can. I found out about this while testing Trisquel kernels on Ubuntu. (Generic Linux-libre kernels don't work on my ASUS ZenBook, for some reason.)
Hope everyone's been doing well!
- Bandicooty98
Linux-libre should not *ship* with proprietary modules. It does not, as far as I know. No work is done to purposefully prevent proprietary modules from loading. That would be DRM!
Not DRM, but violation of Freedom Zero.
There is a bug in Linux-libre though: The work to prevent the inducement of people to load the firmware, via error messages that get reported, also has the side effect that the proprietary junk doesn't get loaded even if it's present. That the firmware loader is still working means that Trisquel's kernel is not being sufficiently deblobbed. The firmware loader is only one matter: I had already been concerned that Trisquel's kernel contained freedom problems because of a series of things:
1. The kernel used in Ubuntu is modified, and adds more proprietary junk than what exists in upstream (from kernel.org) meaning that...
2. Trisquel needs to modify the Linux-libre deblob scripts to deal with this situation because the Linux-libre scripts only catch the blobs from upstream Linux (from kernel.org) and yet...
3. The Trisquel helper runs the deblob scripts with --force (look at the package helper) and in this way if the script encounters a problem with deblobbing it goes undetected because the script doesn't error out and then finally...
4. There is no checking of the kernel results, like with deblob-check, to see if Trisquel's kernel has in fact been fully deblobbed or if problems remain.
Firmware loader is not firmware. As long as the loader itself remains free/libre, it's existence shouldn't be a freedom issue. For Trisquel and any other free/libre distribution, just stay away from including any non-free firmware, and it's enough. The firmware loader is harmless as long as it has nothing to load. But if the user insists to load non-free firmware, Trisquel should not block the user from doing so, as this is his/her Freedom Zero.
For example, we host installation feasts and help participants install GNU/Linux on their computers. We don't actively install non-free firmware for the users, nor do we hint them that we have copies of non-free firmware. But if the users strongly demand that we install such proprietary junks for them, we install for them, since we respect their Freedom Zero (in this case, the freedom to lose freedom).
"Firmware loader is not firmware. As long as the loader itself remains free/libre, it's existence shouldn't be a freedom issue."
But it does present the issue of the kernel complaining about missing proprietary junk when it's not present. On a machine with the upstream kernel from kernel.org check the system log and you'll find complaints about "missing" files and "file not found" messages, etc. Alexandre Oliva (the maintainer of Linux-libre) along with RMS have taken the position that these such messages count as "inducements" or "recommendations" or "steering" people to the non-free junk, since their system keeps telling people basically "hey these files are missing!" And thus they wish to remove that. But that raises the bug I mentioned where it's hard to do that and still have it work. That's what causes some people to think that Linux-libre has the goal to block non-free firmware but that's not a project goal. The goal is not not have the kernel complain when it's not present, not to prevent people from loading them if they wish to. Not having the kernel complain while still retaining the ability to load them when they're not present is a very difficult problem to solve which is why it hasn't been already.
But my concern isn't about the firmware loader directly anyway; it's a symptom of a larger issue. That it's still functioning indicates that the deblob scripts did not touch it - and they're programmed to do so - and if they did not touch that, what else have they not touched? As explained in my previous message there's no checking going on (use of --force, not using deblob-check afterwards) to ensure that a complete deblob happens.
I think the Hyperbola project has a point: The Linux kernel is *definitely* proceeding down an unstable path. And it'll only get worse. Maybe Trisquel should also switch to OpenBSD as a base. The people who develop Linux clearly do not care about software freedom. Deblobbing will become increasingly difficult.
Thank you so much jxself for this clear and concise explanation of the differences between the Trisquel deblobbed kernel and the Linux-libre kernel, as derived from the same given upstream kernel.
Reading the procedure explained here [1], it is difficult to decide to what extent adapting the deblobbing process to the Ubuntu kernel affects the outcome.
Hello,
Thanks jxself for remaining vigilant.
Thanks bandicooty98 for bringing to light what you discovered.
No problem! ^^
- Anmelden oder Registrieren um Kommentare zu schreiben