What are the implications of including binary blobs in the Linux kernel?

Question

According to this there are compelling reasons for caution when installing obfuscated binaries. Knowing this, how can running binary blobs as a part of the Linux kernel be acceptable from a security point of view? There exists a blob-free version of the kernel. The motivations behind that project seem to be primarily ideological. But what kind of risks do users of non-free driver modules actually face? Can a binary blob contain a rootkit designed to take over or open a backdoor into the entire system? How could such a backdoor be detected?

Answer 1

1. From a security, and even ideological, point of view; blobs are unacceptable.
   whatever people say, they are trying to dissuade you from the importance of this issue.
2. the risks users of non-free software face, be it a firmware blob, driver blob, or Microsoft Windows, are vastly unmeasurable. and while it is safer using any Linux distro than Windows, it doesn't mean that any Linux distro is secure.
3. blobs, depending on their size, can do just about anything, they are little programs after all.
4. as for detecting backdoors and other security flaws, there is only one way, and it is quite simple;
   publish the source code. the previous answer points out that:
   "A binary will be much faster than other code." Liar, Liar, Pants on Fire.
   
   a blob will only make the final compiling process of the program faster, not the program itself,
   but regardless of program performance decisions,
   there's no reason not to publish the source, and compiling instructions of that "blob"
   and anyone telling you otherwise is either lying, of some kind of NSA, FBI agent.

---

if you are interested in a 100% FOSS (free and open source) operating systems,
that consciously maintain their code to be blob free, here is a link: Free GNU/Linux distributions
other relevant links:
What is free software?,
techrights.org/2013/11/25/freedo-and-nsa-code/
.

Answer 2

Binary blobs in the Linux kernel are primarily firmware for peripheral devices.

Many peripheral devices - e.g. Wi-Fi cards are notorious for this - have processors inside them. Those processors run code. The code has to come from somewhere. It comes from the driver.

Your Wi-Fi card simply will not work unless the Wi-Fi driver copies firmware into the Wi-Fi card's memory and starts it running.

Usually, the manufacturer of the Wi-Fi card gives out copies of the firmware and says "here is the firmware you need. Your driver should install it using these instructions."

The main risk is that we don't know what's in that firmware. It runs on the Wi-Fi card's processor, so there is usually no risk to the rest of the machine, except for DMA attacks. However, it could see all your Wi-Fi traffic and phone home, if it wanted. We can't tell since we don't have the source code.

Regarding DMA attacks: Many peripherals have the ability to directly write data into the computer's main memory. This is useful because the CPU doesn't have to waste time shuffling data around. But it also means that if the peripheral was malicious, it could overwrite something important, like kernel code, and then install a rootkit. Some computers have a facility called an IOMMU, which prevents this by limiting which addresses can be accessed by peripherals, the same way a regular MMU limits which addresses can be accessed by non-kernel programs.

Answer 3

The main reason they incorporate binaries is for speed. A binary will be much faster than other code, so it's handy since it's so deeply built in to the kernel especially.

How can this be acceptable? Because it is assumed that they were not made with malicious intent. If you are truly worried about this, you can compile the kernel from scratch yourself so you can vet the code that goes into these binaries yourself. The second part is making sure that they havent changed to something thats unknown.

By non-free driver modules I assume you mean something purchased for use on the system. They are exactly the same amount of security as anything proprietary. Meaning that you don't know what's inside them and so if you trust the manufacturer of the software then great! let's hope they didn't feel malicious before they compiled down to binary.

Could a binary be designed to rootkit a system? Absolutely!! This is the same point I just made. Even a seemingly harmless binary could have a replica made that did the same thing and also was a rootkit.

How could such a backdoor be detected? Several ways. The best answer is file integrity monitoring. Even something that takes a simple MD5 or another simple one way hash of simple locations like /etc or just each of the binary files to make sure that someone hasn't changed them. And of course the usual suspects like antivirus, antispyware, and a good firewall.