openSUSE without kernel binary blobs?

Questions which I still hope to get an answer to:

  • What does “Dual” mean (ref. post #4)

  • Question 3 from the OP

  • What would be the effect of uninstalling ‘kernel-firmware’ package? The main concern is not to put the system in an unbootable/broken state, so please explain how to verify if everything will work after this limited “deblobbing” as I am interested to give it a try (if it is possible and safe)

Regarding the use of blobs,
AFAIK and IMO it all comes down to where the binary comes from.

The main objection to binaries is that unless you are able to de-compile, there is no way to know for sure whether the binary contains “extra” instructions from an unknown and possibly malicious source.

So,
it really comes down to where the binary comes from, whether the source that created the binary is publicly available and the security measures in place to ensure that the binary contributed to your project has its integrity intact.

I don’t think how the kernel is built is inconsistent with openSUSE’ fairly strict standards restricting re-distributed applications, one of the primary purposes is to distribute pre-compiled apps so the compiling doesn’t have to happen on User machines. On openSUSE, source is available for every package so that it can be checked, and each step from OBS to the client machine is made secure, and AFAIK everything including any binaries included in the kernel are from trusted sources.

TSU

It’s the License – the Awk commands possibly stripped off some information – take a look at the complete modinfo output for the modules containing the files which triggered the “Dual” text:*GPL
GPL V2
GPL with additional rights
Dual BSD/GPL
Dual MIT/GPL
Dual MPL/GPL
Proprietary
*
See: <http://tldp.org/LDP/lkmpg/2.6/html/x279.html&gt;

Thanks dcurtisfra!

Any idea about the other 2 questions?

I would try this only on a “Server” system – no GUI.

  • There is a chance that, the lack of the Kernel Firmware would allow at least an ASCII terminal session to examine the effects of the state – it is after all, the same as the system state during the boot process before the Firmware is loaded …

Reading the “Freetardism” article, my conclusions are:
[ol]
[li]GNU, Free Software Foundation, Open Source, GPL, is mostly (99.999%) about Software Programs – in other words, applications …[/li][li]The Open Source Kernels are a, very, special case:[/li][/ol]

[LIST=|INDENT=2]
[li]They are the layer between the Hardware we purchase and, the Software Programs we execute on the Hardware Platforms we’ve purchased.[/li][li]The Hardware we purchase is commercial – not Open Source …[/li][li]By purchasing Hardware, we’ve also purchased Licenses related to that Hardware.[/li][li]When we purchase Hardware, we pay for expected Hardware behaviour …[/li][/LIST]
The “Freetardism” folks, seem to believe that, simply by purchasing items one purchases the right to dictate how the Vendor of the item(s) shall behave with respect to the ethics of Open Source …
[ul]
[li]My view is, there ain’t an Industrialist anywhere on this planet who would bow to such customer views and/or dictates – in business terms, this means accepting the payment and ignoring what the customer has said – with the exception of that customer who purchases 90 % of the company’s products brought to the market …[/li][/ul]

Possibly but, it’s up to you with the Hardware you’ve purchased …

According to the Wikipedia article on Linux-libre, openSUSE Tumbleweed offers, as an alternative, a Linux-libre kernel – I don’t have any Tumbleweed systems and therefore, I have absolutely no way to confirm this information …

Thanks for the answers!

How would you:
(A) check that everything works after the change
(B) “undo” the change (in case something doesn’t work as expected)
?

Check the contents of the /lib/firmware/ License files for anything related to your Hardware.
Search all the license files in /usr/ for licenses related to your Hardware.

  1. Before executing the test, document all the applications executing on the system and, write the Test Cases needed to prove correct execution.
  2. After booting the “no firmware” system, execute the Test Cases to prove that the applications still execute as expected.
  3. If the applications do not perform as expected, invoke YaST from the CLI (yast2) to reinstall the Firmware package.

I am using the nouveau driver. Does that change anything in your suggestion? Or should I still set default runlevel 3 (or anything else)?

…] examine the effects of the state …]

How do you do that?

  • When we purchase Hardware, we pay for expected Hardware behaviour …

I have never expected to have something as terrible as Intel ME. So since I learned about it I disabled it :slight_smile:

Check the contents of the /lib/firmware/ License files for anything related to your Hardware.
Search all the license files in /usr/ for licenses related to your Hardware.

Are you suggesting a comparison of


lspci | grep -Eio "driver.*"
lshw | grep -Eio "driver.*"

with the contents of those directories? It is really difficult to find exact matches. I hope you can clarify that process as the output is quite long.

‘ps axf’?

and, write the Test Cases needed to prove correct execution.

What does this mean? (ELI5 pls)

  • After booting the “no firmware” system, execute the Test Cases to prove that the applications still execute as expected.
  • If the applications do not perform as expected, invoke YaST from the CLI (yast2) to reinstall the Firmware package.

I am worried about a situation in which the system won’t boot because it cannot use properly an essential device (e.g. disk drive) because when it is in such a state it would be impossible to reach yast and all that. So I am trying to figure if the essential devices would work. Then if the system boots one can look for errors etc. Any ideas how to take care of this in particular? Maybe I should just build a “libre kernel” and add it to grub, so I can reboot with the regular one in case of failure. But then the question is how the (still installed) ‘kernel-firmware’ package will work with the “libre kernel”, i.e. will the system still use the blobs provided by ‘kernel-firmware’ package or will those be ignored as if the package is not installed.

In any case I am careful not do anything irreversible during this test. So I hope you can clarify a little more.

Hi
Just craft a script to use the output from lsmod, then check the output from modinfo for the existence of ‘firmware’, then you can make a call… for example the oss amdgpu and iwlwifi drivers I use needs firmware… broadcom devices are another.

Hi again :wink:
Your nouveau driver uses firmware… what card do you have?

That’s a little difficult for me. Could you please be more specific?

Of course it does. The question is whether some important part of it from this firmware comes from the OS as discussed above. On the machine where I will be testing this there is GTX680

The graphics firmware is supplied as part of the ‘kernel-firmware’ package (assuming that is what you’re asking here).

I have checked this list and compared it to this and this. I don’t see anything about GK104 in ‘kernel-firmware’ repository at all.

Obviously the ‘kernel-firmware’ package provides some blobs for other cards but not for this one. Or are you talking about something else?

Hi
Something like this;
https://wiki.debian.org/Firmware#firmware-script

But if used against just your module output, should indicate if you have anything requiring firmware.

Searching the NVidia world, I notice that, the GTX680 (GK104) will probably need a legacy proprietary NVidia driver: <NVIDIA Driver Downloads; <Page Not Found | NVIDIA.
There’s also this Linux Mint article: <Which driver for NVIDIA GK104? Nothing in additional drivers - Linux Mint Forums.
The openSUSE SDB is here: <https://en.opensuse.org/SDB:NVIDIA&gt;.
[HR][/HR]Given that, you’ll need the proprietary driver for your GPU – there doesn’t seem to be anything in “/lib/firmware/nvidia/” related to the GK104 and, I can’t see anything in the Nouveau packages – but, I could be mistaken – the chances that, the proprietary driver will load some firmware are possibly quite high …

If the GTX680/GK104 hardware is supported by the Nouveau driver – this Phoronix article indicates that it may be: <OpenGL Compute Shader Support Lands For Nouveau GK104 & GM107+ - Phoronix; – then the systemd default target for boot should be set to “multi-user.target” which is the same as the “runlevel3.target” – which is the case for a “Server” system – “systemctl set-default multi-user.target”.

My apologies: “typing speed slower than the thoughts … ” – “examine the effects of the state”: meaning the “broken system state” – if the lack of the Kernel Firmware means that, the boot breaks before reaching the Multi-User target, it should still be possible to us a tty1 VT session to examine the cause of the failed boot and, to reinstall the Kernel Firmware package to allow a reboot to a running system.

  • If the Network breaks due to failed boot, you’ll have to ensure that, you have the ‘kernel-firmware’ package on the system’s boot disk.

My point is, when we purchase Hardware, we also purchase an allowance – a licence – to use any associated Firmware and/or Microcode.

Yes, and, it’s “Sisyphos work” – laborious …

Or, simply a knowledge of which user applications are usually run on the machine.

Your efforts to determine if, the Kernel Firmware can safely be removed, or not, can either be executed on an unplanned “Trial and Error” basis or, as a formal Test scenario.

  • IMHO, and experience, a formal Test beats “Trial and Error” hands down every time.

In formal Testing, we first plan and specify the Tests to be executed. And then, we formally write Test Cases for each part of the Testing process.

  • A Test Case is a sequence of Test Steps which are executed as part of the Test process.
  • Each Test Step is a note of what shall be done to determine if the system is behaving as expected.

It’s a bit like the pre-flight checks performed by pilots before they leave the ground.

If you simply check the system’s behaviour in an unplanned way, you may well miss some important behaviour of the applications which are normally run on that machine.

If the system is running in “Server” mode, then the CLI command “yast2” will bring up a “curses” version of YaST which runs on a VT – no graphics …

I suspect that, Tumbleweed offers it’s Libre Kernel as part of the GRUB list.

In the worst case, you’ll have to re-install the System …

Instead of risking to make my system unbootable I found an old hard drive, disconnected all currently used drives and installed Leap 15.0 on it (formatting it and deliberately not installing kernel-firmware). The result:

All hardware works fine. I don’t see any special errors or warnings in dmesg or journalctl. Also /lib/firmware contains only 2 files:


$ l /lib/firmware/
total 12
drwxr-xr-x 1 root root   60 Jun  7  2018 ./
drwxr-xr-x 1 root root   78 Mar 11 11:36 ../
-rw-r--r-- 1 root root 4196 Feb 13 15:16 regulatory.db
-rw-r--r-- 1 root root 1182 Feb 13 15:16 regulatory.db.p7s

Then I mounted the old hard drives too and I was able to access them without issues (still using the freshly installed Leap).

I also ran the following test (and that shows a difference):

On the system without kernel-firmware:


# find /sys/devices/system/cpu/vulnerabilities/* -print -exec cat {} \;
/sys/devices/system/cpu/vulnerabilities/l1tf
Mitigation: PTE Inversion; VMX: conditional cache flushes, SMT disabled
/sys/devices/system/cpu/vulnerabilities/meltdown
Mitigation: PTI
/sys/devices/system/cpu/vulnerabilities/spec_store_bypass
Vulnerable
/sys/devices/system/cpu/vulnerabilities/spectre_v1
Mitigation: __user pointer sanitization
/sys/devices/system/cpu/vulnerabilities/spectre_v2
Mitigation: Full generic retpoline, STIBP: disabled, RSB filling

When booting the regular system which is with kernel-firmware:


# find /sys/devices/system/cpu/vulnerabilities/* -print -exec cat {} \;
/sys/devices/system/cpu/vulnerabilities/l1tf
Mitigation: PTE Inversion; VMX: EPT disabled
/sys/devices/system/cpu/vulnerabilities/meltdown
Mitigation: PTI
/sys/devices/system/cpu/vulnerabilities/spec_store_bypass
Mitigation: Speculative Store Bypass disabled via prctl and seccomp
/sys/devices/system/cpu/vulnerabilities/spectre_v1
Mitigation: __user pointer sanitization
/sys/devices/system/cpu/vulnerabilities/spectre_v2
Mitigation: Full generic retpoline, IBPB: conditional, IBRS_FW, RSB filling

I don’t know if that matters but on the later system there are additional kernel command line parameters which are not present on the first one:


elevator=deadline mem=33554428k kvm-intel.ept=0

I couldn’t think of any other tests for comparison, so please let me know if you can suggest any.

For this particular comparison: I have no idea what “STIBP: disabled” means and why it is present only on the first system. I also wonder what would be the way to have the full set of mitigations on it (which seems to be through BIOS/UEFI update as Intel recommends).

I also have not build from source “Libre kernel” as per question 3 in the OP. I don’t know if it is necessary, i.e. if kernel-default package contains blobs or they are completely isolated in kernel-firmware. If anyone can share info about it that would be helpful as I don’t know where else to ask.

BTW I wonder why the kernel-firmware is not on the Non-OSS repo. It is not open source obviously.