Libre (deblobbed) FreeBSD derivatives like Linux-libre systems?

HD Scania

HD Scania

From Linux I can easily find and have been using Linux-libre systems as the deblobbed ones, but for BSD systems I only know openBSD-derived LibertyBSD and never have found the similar deblobbed systems those are FreeBSD or NetBSD derived, the most important is openBSD is aging and breaks my GPT drive, but have fortunately and ultimately rescued under gdisk, but I need to know this fortune is not always come to me.
 
On LiberyBSD: That project is nonsense. OpenBSD has always had a strong stance against Blobs. They even made a release song about this. If OpenBSD runs without blobs (it does for example on my Pine 64) it will always be blob free, if it doesn't then it will get blobs. So it's really just depending on what hardware you use/buy. If you buy hardware that won't run without blobs (eg. Raspberry Pi) then that's your decision to run blobs, unless you yourself are reverse engineering, in which case you most likely again want blobs.

A famous example of Blobs are USB devices that simply will not work, unless some OS (Windows, Linux, BSDs, etc.) put their firmware on them. Once that is done it will work everywhere, but if you use any such USB device (you likely use some form of USB, maybe even internally) and you pretend to run blob-free you are lying to yourself. The same is true for your BIOS (unless you use libreboot) or if you use any Intel or AMD processor (Microcode), etc. So just please don't say your system is deblobbed. It's not. Not even running the FSF endosered Replicant (Android) will result in running a system that doesn't have blobs.

Another way to put it. If you remove the blobs from OpenBSD for example you actually remove the most harmless form, cause they are just lying there as files until you need them. If you don't need them they will just be files, no different from cat pics you might have on there.

For FreeBSD it's not all too different. Unless you install from ports the only blobs there are (active, so executed/flashed/..) are the ones you need. So you already made the choice by buying hardware that must run with blobs. Again, most famous example and a reason why the OpenBSD and many other actual developers interested in open hardware don't like them so much are Raspberry Pis.

In other words: Deblob the world by refusing to use/buy hardware requiring or containing blobs (CPUs, Motherboards, BIOS, USB devices, network cards, firmware of hard drives, etc.) and not by trying to use systems that lie to you about blobs. Just because they are not in some directory it doesn't mean they are not there and required. And make a distinction between images of blobs lying somewhere, not being active and stuff that's actually running inside your hardware right now, even in systems that are considered or labeled open (refurbished phones, laptops, etc.).

But to get to the actual answer. It's actually not too hard to remove the firmware directories, and create images without them. Either remove them from your system manually (rm -rf the directory) or even use a tool such ass mfbsd, corchet, etc. to create images without the directory containing them.

By the way. The OSs will log when they use firmware. So they are pretty nice for detecting hardware that requires them.

I hope some part of that response helped. :)
 
My hardware system is not supported by LibreBoot so I am just soft-deblobbed and cant be hard-deblobbed, which my OS are libre ones, like Parabola and Trisquel. So how to prevent installing blobs while installing FreeBSD? Just disable every nonfree repo but nonfree drivers and firmware cant be disabled? :)
tobiam said:
On LiberyBSD: That project is nonsense. OpenBSD has always had a strong stance against Blobs. They even made a release song about this. If OpenBSD runs without blobs (it does for example on my Pine 64) it will always be blob free, if it doesn't then it will get blobs. So it's really just depending on what hardware you use/buy. If you buy hardware that won't run without blobs (eg. Raspberry Pi) then that's your decision to run blobs, unless you yourself are reverse engineering, in which case you most likely again want blobs.
A famous example of Blobs are USB devices that simply will not work, unless some OS (Windows, Linux, BSDs, etc.) put their firmware on them. Once that is done it will work everywhere, but if you use any such USB device (you likely use some form of USB, maybe even internally) and you pretend to run blob-free you are lying to yourself. The same is true for your BIOS (unless you use libreboot) or if you use any Intel or AMD processor (Microcode), etc. So just please don't say your system is deblobbed. It's not. Not even running the FSF endosered Replicant (Android) will result in running a system that doesn't have blobs.
Another way to put it. If you remove the blobs from OpenBSD for example you actually remove the most harmless form, cause they are just lying there as files until you need them. If you don't need them they will just be files, no different from cat pics you might have on there.
For FreeBSD it's not all too different. Unless you install from ports the only blobs there are (active, so executed/flashed/..) are the ones you need. So you already made the choice by buying hardware that must run with blobs. Again, most famous example and a reason why the OpenBSD and many other actual developers interested in open hardware don't like them so much are Raspberry Pis.
In other words: Deblob the world by refusing to use/buy hardware requiring or containing blobs (CPUs, Motherboards, BIOS, USB devices, network cards, firmware of hard drives, etc.) and not by trying to use systems that lie to you about blobs. Just because they are not in some directory it doesn't mean they are not there and required. And make a distinction between images of blobs lying somewhere, not being active and stuff that's actually running inside your hardware right now, even in systems that are considered or labeled open (refurbished phones, laptops, etc.).
But to get to the actual answer. It's actually not too hard to remove the firmware directories, and create images without them. Either remove them from your system manually (rm -rf the directory) or even use a tool such ass mfbsd, corchet, etc. to create images without the directory containing them.
By the way. The OSs will log when they use firmware. So they are pretty nice for detecting hardware that requires them.
I hope some part of that response helped. :)
Click to expand...
 
HD Scania said:
Just disable every nonfree repo but nonfree drivers and firmware cant be disabled? :)
Click to expand...
But firmware is hardware. In the end it really is the same as your BIOS.

Nonfree drivers you can simply not install. You can also use the license flags for ports.

In the end all the BSDs including OpenBSD (without the LibreBSD part) are soft deblobbed as you call it. Firmware is part of hardware. So as lebarondemerde stated, simply don't use any hardware (and to do so disable the according driver) that requires firmware. There is no point in having drivers for hardware you cannot use anyway.

It seems that (most?) firmware blobs are uu-encoded. So you should find them with this command: find /usr/src/sys -name "*.uu"
 
What is the purpose of the original question?

If it is: "run only code where I have access to the source code", you have already lost. Your disk drive contains millions of lines of code, and it is guaranteed that Seagate/Hitachi/SanDisk/... will not let you see that source code. Same with your HBA (a.k.a. disk controller), which usually contains a microcontroller (often a 32-bit machine today), with hundreds of thousands of lines of source flashed into it. Keyboard and mouse, same thing. Even displays have controllers today. Matter-of-fact, much computer hardware has firmware versions, and the better ones allow the end user to control and upgrade firmware versions. See for example the discussion a week or two ago here about which firmware version is best on LSI SAS HBAs. Note that has nothing to do with "blobs" (whose management, loading and execution are under control of the OS), but firmware that's stored in the hardware device, and requires special out-of-band access to upgrade.

And also note that there have been suspicions that disk manufacturers include spyware on the drives themselves. A little google will find you many stories. An interesting tidbit that confirms those suspicions: In the last decade, there has been a wave of mergers of disk drive manufacturers (I include SSDs and flash here under disk drives), and some of those mergers had to be stopped due to political considerations: Neither the US, nor Japan, nor China will allow *all* disk drive manufacturing to be under complete control of foreign entities, so for the time being the world is in a situation where there is at least one disk drive maker in China and one in the US.

Completely de-blobbing an environment is not a goal in itself, it is a means to reach a certain goal. Dear HD Scania, please explain what you are really after; maybe then we can give you additional advice.
 
Interesting. Just looked at the Raptor Talos web page. It's fascinating how Raptor openly advertises that their system is more secure, with all the code being open. They explicitly talk up the threats of your data otherwise being visible to cloud provider, government, or competitors. Charming.

What they deliberately omit: Your data is also stored on disks, and transits over HBAs and network cards. Any chance you can get Seagate, Hitachi, LSI=Avago=Broadcom and Mellanox to open their firmware in their devices to you? No. How many lines of code are running in your network switch? In its SNMP management engine? Do you know that code? No.

Deblobbing and opening up the sources for auxiliary components (such as boot loaders, management controllers, ...) is not worthless, it's a small part of an overall effort to secure your data center. Claiming that fixing just boot loaders and management controllers solves the data security problem is selling snake oil, and explicitly dishonest.

But lets get back to the OP: Why do you want to deblob? What's your motivation? How does it fit into your overall plan? If you give us more detail, we can help you better.
 
FWIW, the network domain (any traffic that travels through a network) is currently the easiest point to figure out if something in your device is trying to leak your information, because you can build your own monitoring device and monitor all traffic that exists your device. Note: I didn't say that it is easy, just that it currently is the easiest point.
And if you don't trust the network monitoring device you have built, it gets harder.
 
Under my experiences in GNU systems and Debian, my only nonfree hardware are my wifi card, which I have been now looking for a libre wifi card, at least this card needs to be Trisquel compatible (Trisquel is an GNU system), as listed under ThinkPenguin, which is to provide libre hardware replacements instead of the nonfree hardware mostly found in the computing arcades which you are living in a metropolis.:)
For BIOS this is my ONLY AND LAST hardware I worry that RISK TO BRICK the machine. I have now installed an EFI system named rEFInd, which is loaded after hardware i.e. BIOS and before kernels i.e. my libre OS, which helps to bypass against the BIOS backdoors for my libre OS, being libre also stands these OS for FATALLY low risks against the generic malware.
tobiam said:
But firmware is hardware. In the end it really is the same as your BIOS.
Nonfree drivers you can simply not install. You can also use the license flags for ports.
In the end all the BSDs including OpenBSD (without the LibreBSD part) are soft deblobbed as you call it. Firmware is part of hardware. So as lebarondemerde stated, simply don't use any hardware (and to do so disable the according driver) that requires firmware. There is no point in having drivers for hardware you cannot use anyway.
It seems that (most?) firmware blobs are uu-encoded. So you should find them with this command: find /usr/src/sys -name "*.uu"
Click to expand...
 
When using ARM devices, it seems there are only a few options for hardware that can run blob-free (from the firmware perspective). My reading of Parabola Linux site info indicates that Banana Pi and Beaglebone are possible to run "blob free" (with respect to things other than the internal controller codes). Are there other devices that can work?

If Parabola will run on those boards without blobs, then I'd guess that FreeBSD could be "blob free" when running on them. I suppose this is a topic for the other sub-forum.
 
You must log in or register to reply here.
Back
Top