Hi,
I have just read that openSUSE has binary blobs in its kernel.
Some questions which arise in my mind:
Is deblobbing the linux kernel a freetardism and how bad is it actually to have blobs?
In case it comes down to hardware support (which may depend on particular blobs) - how can one check if there is such hardware which needs those blobs?
Is this a valid/recommended procedure for switching to a “Linux-libre” kernel or is there a better way?
Given that, the binary blobs that matter for most of us, contain CPU, APU and GPU firmware, it depends on whether one wishes to use modern CPUs with firmware or, CPUs constructed using hardware modules with TTL gates and/or transistor arrays …
Please be aware that, AFAIK, CPUs with firmware began to appear around 1975 – at least in the Mini-Computer scene …
I don’t actually know if that is true. However:
http://download.opensuse.org/repositories/Kernel:/stable/standard/
which you can add as an extra repo, and install kernels from there. And, again, there is a vanilla kernel in that repo.
Personally, I am just using the standard “kernel-default” with Leap 15.0. But I do have the kernels repo configured, though I normally leave it disabled. I did just enable as a quick check. The “kernel-vanilla” from there is 5.0.0, so it is newer than even the current Tumbleweed kernel.
[QUOTE=dcurtisfra;2896281]Given that, the binary blobs that matter for most of us, contain CPU, APU and GPU firmware, it depends on whether one wishes to use modern CPUs with firmware or, CPUs constructed using hardware modules with TTL gates and/or transistor arrays …
Please be aware that, AFAIK, CPUs with firmware began to appear around 1975 – at least in the Mini-Computer scene …[/QUOTE]
For CPU I have read only about microcode updates (and I wonder why on openSUSE dmesg shows:
0.000000] microcode: microcode updated early to revision 0x20, date = 2018-04-10
while on intel.com there is a version 20180807.
It is the first time that I read about firmware in CPU. Could you please elaborate?
Also - why would one rely on the OS to update firmware?
APU - the only info I found is this and since I am not using AMD (and not planning to) I guess it is not an issue.
GPU - are you saying that the distro maintains my discrete video card’s GPU and without it it won’t be able to work? I have never heard of anything like that so far.
From what I read on the web the vanilla kernel also contains binary blobs.
- If there are binary blobs, they are probably in the “drm” module. You could just uninstall that.
Unfortunately “probably” doesn’t really help here. BTW with a little more searching I found some sources explaining that a package called linux-firmware is the one which contains blobs on other distros. On openSUSE I see a package kernel-firmware which shows a link to a repository with the same name. However that doesn’t really say what is the situation with the rest of the kernel.
- You can download kernel sources and build your own.
Please correct me if I am wrong but AFAIU that’s vanilla too. (= your 1.)
Another source suggests a check on licenses of modules like this:
modinfo $(lsmod | cut -d' ' -f 1) | awk '/filename/{fn=$2;} /license/{print $2, fn;}'
which in my case shows:
Dual /lib/modules/4.12.14-lp150.12.48-default/kernel/drivers/gpu/drm/drm_panel_orientation_quirks.ko
Dual /lib/modules/4.12.14-lp150.12.48-default/kernel/fs/nls/nls_cp437.ko
Dual /lib/modules/4.12.14-lp150.12.48-default/kernel/fs/nls/nls_iso8859-1.ko
...
GPL - for all others
I wonder what “Dual” means and what these 3 are needed for.
Generally my initial questions pretty much remain.
CPUs have come a long way from the concept of “only some logic gates” things such as discrete ALUs (Arithmetic Logic Units).
Modern CPUs are complex beasts with various buses and channels performing pipe-lining of instructions and the instructions in parallel …
Therefore, Firmware – to allow modification of the CPUs behaviour at the customer’s site – both yours and, mine …
You have to rely on someone with good contact to the CPU manufacturers …
Take a look in ‘/usr/share/licenses/kernel-firmware/’ and ‘/lib/firmware/’ …
If the firmware can not be loaded at boot time, the device will not behave as expected …
That’s likely true for openSUSE also.
But why? If I want to update my BIOS - I download the update and do it myself. Same for SCSI controller or whatever. Why should the CPU be any different? IOW: why should the distro be a mid-man? I mean - I not that I do or don’t mind, just want to know why this is made to be like that.
Take a look in ‘/usr/share/licenses/kernel-firmware/’ and ‘/lib/firmware/’ …
How to the so called “Libre” distros run without all that? Are they any worse?
If the firmware can not be loaded at boot time, the device will not behave as expected …
Again - how come “Libre” distros work without that?
Also - I certainly don’t flash my BIOS on each boot. And I would be definitely concerned to find out that a firmware-level updated can come through the OS update. I have never thought that the OS would touch anything below Ring 0. Is that something new?
Sorry if these questions sound dumb. I have just stopped following closely how CPUs evolve after Pentium 4 
There is no such package in openSUSE Leap. Or do you mean ‘kernel-firmware’?
Yes. (please ignore this extra padding to keep the forum software happy).
In your post #4 you provided this link: https://downloadcenter.intel.com/download/28087/Linux-Processor-Microcode-Data-File?product=873
Did you read the “Detailed Description” part?
It actually provides an answer to your question:
“CPU microcode is a mechanism to correct certain errata in existing systems. The normal preferred method to apply microcode updates is using the system BIOS, but for a subset of Intel’s processors this can be done at runtime using the operating system. … Microcode states are reset on a power reset, hence its required to be updated everytime during boot process …”
I never used a “Libre” distro and all i know about them is what one can read in Wikipedia :
“… The downside of removing proprietary firmware from the kernel is that it will cause loss of functionality of certain hardware that does not have a free software replacement available …”
As far as my Bluetooth-adapter is concerned i can confirm this statement. The adapter will not provide certain BT profiles without its firmware being loaded. Yet i didn’t dare to test how my Intel CPU does without its microcode.
Regards
susejunky
So similar to what I would prefer Intel also says that the “normal preferred method to apply microcode updates is using the system BIOS” adding that it “can be done at runtime using the operating system”. Then the question transforms to: why don’t we do it the way the manufacturer recommends and why does the distro use the other way, instead of recommending the recommended one?
Doesn’t that also contradict the recommendation of the manufacturer? If it is possible to do it once throug the BIOS, why should the OS do it on every boot?
Yet i didn’t dare to test how my Intel CPU does without its microcode.
Are you saying that your CPU may not work without the microcode provided by the distro? Makes no sense.
Updating the firmware/microcode of a device via BIOS/UEFI implies installing a (new/updated) BIOS/UEFI which includes the updated firmware. Is that correct?
Who should provide all those new/updated BIOSs/UEFIs?
If firmware updates had to be done exclusively via BIOS/UEFI then - on every required firmware update - the manufacturer (of the device to be updated) had to contact all motherboard manufacturers who sell (and once sold!) boards which can handle that specific device, hand them over the new firmware and ask them to update their BIOS/UEFI for the boards in question and to provide these new/updated BIOSs/UEFIs to their customers.
I can recall at least three intel microcode updates within the last twelve months (and my system contains several more devices which make use of firmware which in turn gets updated more or less frequently) so i can’t believe that updating firmware/microcode exclusively via BIOS/UEFI would work.
No! I said: I have not tried to run my system without the CPUs microcode (and i certainly never will because i do not want to make my system vulnerable to known CVEs which intel fixed by microcode).
Nevertheless i would be very interested to know how a system performs without the CPUs microcode. So if you do have any practical experience in this please share it here.
Regards
susejunky
I don’t know. I am reading what Intel writes and asking.
Who should provide all those new/updated BIOSs/UEFIs?
Assuming that the answer to the above is “yes” (and I don’t know if such assumption is correct for microcode in particular) that should be the motherboard manufacturer.
If firmware updates had to be done exclusively via BIOS/UEFI then - on every required firmware update - the manufacturer (of the device to be updated) had to contact all motherboard manufacturers who sell (and once sold!) boards which can handle that specific device, hand them over the new firmware and ask them to update their BIOS/UEFI for the boards in question and to provide these new/updated BIOSs/UEFIs to their customers.
I don’t read anywhere “exclusively”. I read “recommended”. Also what you explain may be incorrect. To my mind the CPU manufacturers should publish updated microcode, the MB manufactuers should download it and update BIOS/UEFI accordingly, and the end user should in his turn follow the updates of the MB manufacturer. I.e. - nobody should “contact” anyone, just like nobody contacts me to update the version of openSUSE.
I can recall at least three intel microcode updates within the last twelve months (and my system contains several more devices which make use of firmware which in turn gets updated more or less frequently) so i can’t believe that updating firmware/microcode exclusively via BIOS/UEFI would work.
My understanding is that firmware resides in ROM, i.e. needs to be written only once, not on every boot. Then it is read and executes on every boot. So it confuses me to read the replies here which imply that firmware is (in some way) ran by the OS on each boot. Please someone correct me if I am wrong and clarify.
I have not tried to run my system without the CPUs microcode (and i certainly never will because i do not want to make my system vulnerable to known CVEs which intel fixed by microcode).
Nevertheless i would be very interested to know how a system performs without the CPUs microcode. So if you do have any practical experience in this please share it here.
Perhaps you mean the microcode updates. I don’t think it is possible to run the CPU “without the microcode” (as in completely without any microcode) because of what it is and the way it works.
I still hope to get answers to my initial questions.
Unfortunately or, maybe fortunately, the microcode which is loaded at boot-time has to be packaged for the operating system in question.
As pointed out in other replies here, there are devices which absolutely need microcode to be loaded at boot time – in other words the hardware running the “Libre” distribution doesn’t behave as expected …
I suspect the system behaviour at run-time isn’t really that which could be expected of the hardware platform in question …
No it’s not new; AFAIK firmware and microcode have been around since about 1975 – in Mini-Computers – before the IBM-PC was brought to market …
I suspect, yes …
BTW, I’m not suggesting that, Charles Babbage’s “Analytical Engine” (1837) and the code written for it by Ada Lovelace (1843) offer an initial insight into the reasons why firmware and microcode are in fact a good idea … 
No, they’re not dumb.
In fact, I find it quite refreshing that, someone is questioning the current “state of affairs” which people such as myself simply accept without bothering to think about what’s going on …
In a nutshell - At boot, the UEFI firmware (or BIOS) loads the microcode in to the CPU. Microcode updates can be incorporated with UEFI firmware (or BIOS) updates. Updates can also be provided by operating systems to load new microcode at boot time. The Linux kernel loads the update the microcode (CPU firmware) to the CPU’s volatile memory at boot time.
Thanks for the explanations guys.
I have taken the time for a quick refresh of my (as it seems dated) knowledge.
Here is a summary which may be interesting along the lines of this discussion (anyone please feel free to correct anything which is wrong):
Strictly speaking microcode and firmware are not identical.
Firmware:
It’s becoming more common in some types of hardware for its “firmware” to be stored in driver software and loaded onto the device when it’s booted/initialised, instead of leaving it permanently on the device.
…]
Microcode is a subset of this latter type of “firmware”.
(source)
Microcode:
IOW: It makes sense to update microcode through BIOS as it will be available to any OS running on the machine. But OTOH it may be futile considering the possibility of that being replaced by the OS.
Intel “microcode updates” are in fact “firmware” updates in the sense that they update a lot more than just the microcode translation unit of the processor.
These unified processor package updates we call “microcode updates” for Intel also update other on-die microcontrollers (such as the PMU and the power management core) as well as several parameter tables for different on-die processor subsystems. They are rather complex.
(source)
Typically, a microcode patch is uploaded to the CPU by the motherboard firmware (e.g., BIOS or UEFI) or the operating system during the early boot process.
While it is well-known that CPUs are regularly updated with this mechanism, very little is known about its inner workings given that microcode and the update mechanism are proprietary and have not been throughly analyzed yet.
…]
To this end, our microprograms range from CPU-assisted instrumentation to microcoded Trojans that can even be reached from within a web browser and enable remote code execution and cryptographic implementation attacks.
Source: Reverse Engineering x86 Processor Microcode. The white paper also includes specific examples of such microcode Trojans.
To me all that sounds like a quite valid reason to avoid binary blobs and to prefer hardware which has no such proprietary components, rather than rely blindly on the updates of manufactures who obviously created products vulnerable at so many levels.
It seems I am looking for the impossible.
Read these two
https://en.wikipedia.org/wiki/Firmwarehttps://en.wikipedia.org/wiki/Microcode
and you will see that the definitions of these are not 100% set and that some even see them as synonyms.
I have read them earlier and even shared the second link in an earlier post. But thanks. Good to have them in such thread.
Agreed. Given modern technology, IMHO, it’s impossible …
I don’t know if it should be difficult to understand the use of microcode firmware updates…
(Some of the following based on hear-say)
Yes, once upon a time not that long ago (about 10 years ago?) Intel and MS got together and suggested a new way to improve performance applying some new ideas of the time… Up until then, computing architecture had largely been based on strict layers and modularity. Upper layers are built on succeeding lower layers and lower layers could be built to emphasize stability and reliability. But on this particular day, Intel and MS had an inspiration, what if higher layers (ie the OS) inform the lower layer(s) (ie BIOS, other firmware) to re-configure for better performance? And so, a new channel of communications came to be where the firmware could accept instructions from above. But still, from what I’ve seen microcode updates are only pin-holes of functionality by a specified API to remain highly secure (no hacker can send a command that might compromise the CPU or other critical hardware subsystem)
Example 1 I’ve seen where microcode instructions exist.
It’s taken many many years but VMware I think has finally figured out how to take advantage of special I/O and memory management features related to virtualization.
Example 2 I’ve seen where microcode instructions exist.
Mitigations for Meltdown and Spectre (side loading) exploit vectors have been distributed through OS updates, but this is a relatively new feature in Intel CPUs. This suggests that over time, Intel has been carefully expanding the kinds of things available through a microcode update so that a complete BIOS re-flash or CPU replacement is not necessary. Keep in mind that so far, there is no final solution for Spectre and Meltdown through these updates, only the methods used to exploit can be addressed so far… A proper fix is possible only by replacing the CPU altogether.
Bottom line, in this modern world where a number of things around us change with increasing rapidity, this is a way for hardware to continue to have a reasonable lifetime expectation.
HTH,
TSU