You installed FreeBSD. Or OpenBSD. Or Linux from source.

You believe your system is open. You believe you can audit every instruction.

You are wrong.

Your WiFi card loaded a firmware blob. Your GPU loaded a firmware blob. Your SSD has firmware you cannot see. Your CPU has microcode you cannot audit.

The blobs are inside your open source system. The blobs answer to hardware vendors. The blobs see everything.

What Is a Blob?

A blob is a Binary Large Object — compiled code without source. In the context of drivers:

Component	Open Source	The Blob
Kernel driver	Yes (usually)	—
Firmware	No	Runs ON the hardware
Microcode	No	Runs INSIDE the CPU

The kernel driver is the code your OS runs to talk to hardware. You can read it. You can audit it.

The firmware is code that runs on the hardware itself. Your WiFi chip has a CPU. That CPU runs firmware. You cannot read it.

Your open source stack:
┌─────────────────────────────┐
│  Your Application           │ ← You control
├─────────────────────────────┤
│  Kernel                     │ ← You can audit
├─────────────────────────────┤
│  Kernel Driver              │ ← Usually open source
├─────────────────────────────┤
│  Firmware Blob              │ ← PROPRIETARY
├─────────────────────────────┤
│  Hardware                   │ ← Black box
└─────────────────────────────┘

The blob sits between your audited driver and the hardware. Every packet through your WiFi passes through the blob. Every frame your GPU renders passes through the blob.

Why Blobs Exist:

Hardware vendors refuse to document their hardware. They claim:

1. “Trade secrets” — Competitors might copy our register layout
2. “Regulatory compliance” — Radio firmware must be locked (FCC)
3. “Complexity” — Hardware is too complex, firmware is easier
4. “Security” — If you could modify firmware, you could do bad things

Translation:

1. We don’t want to support your bug reports
2. We want to control what frequencies you transmit (valid for radio)
3. We moved functionality off your CPU onto our chip
4. We don’t trust you with hardware you purchased

The Real Reason: The Blobs Are Dirty

There is another reason vendors hide their firmware: the code is stolen.

Firmware teams copy from each other. They use GPL code without attribution. They embed copyrighted libraries without licenses. They “borrow” reference implementations and ship them.

If the source were public:

• Competitors would see what was copied from them
• GPL violations would be exposed
• Lawsuits would follow

The blob is a black box because inside the black box is evidence.

Remember MINIX? Intel took Tanenbaum’s operating system, embedded it in every CPU since 2015, and never told him. He learned from the press. He was never paid. He was never credited.

Intel shipped MINIX in billions of CPUs. Tanenbaum got nothing.

Now imagine what else is inside these blobs. Whose code was “borrowed”? Whose algorithms were copied? Whose GPL project was violated?

The vendors know. The blob hides the evidence. Open source would expose the theft.

And it’s not just stolen code. The blobs contain:

• Backdoors — Intentional or accidental, remote access exists
• Exploits — Vulnerabilities that have existed for years, unpatched
• Embarrassing code — Written by interns, never reviewed, shipped anyway
• Hardcoded credentials — “admin/admin” in firmware since 2008
• Debug interfaces — Left enabled in production

Researchers who reverse-engineer firmware consistently find horrors. Broadcom WiFi had remotable code execution. Intel ME had years of vulnerabilities. Every time someone looks, they find disasters.

The vendors know their code is bad. Open source would invite security researchers. Security researchers would find the bugs. The public would learn how negligent the vendors are.

The blob hides:

1. Stolen code
2. Bad code
3. Backdoors
4. Unpatched exploits

This is why firmware stays closed. Not trade secrets. Crime scenes.

The WiFi Situation:

Almost no WiFi chip works without firmware blobs:

Vendor	Blob Required	Blob Size
Intel	Yes	1-2MB per generation
Broadcom	Yes	Large, often requires wl driver
Qualcomm/Atheros	Mostly yes	Varies
Realtek	Yes	Smaller, but still opaque
MediaTek	Yes	Getting worse
Atheros (old)	Some work without	ath9k glory days

The ath9k driver for older Atheros chips is famous: no firmware blob required. The hardware is simple enough that the kernel driver controls it directly.

These chips are now “legacy.” New Atheros chips require blobs. Progress.

The GPU Situation:

Vendor	Open Driver	Firmware Blob
Intel	Yes (i915)	Yes (GuC, HuC, DMC)
AMD	Yes (amdgpu)	Yes (large, many files)
NVIDIA	No (nouveau barely works)	Massive, signed

Intel and AMD provide open source kernel drivers. But both require firmware blobs for full functionality.

NVIDIA provides no open source driver. The nouveau project reverse-engineers NVIDIA hardware. NVIDIA responded by signing their firmware — nouveau cannot load it, modern NVIDIA GPUs are crippled without the proprietary driver.

Linus Torvalds, on stage, to NVIDIA: “Fuck you.”

This was not unprofessional. This was accurate.

The NVIDIA Special:

NVIDIA’s approach:

1. Release no documentation
2. Release proprietary driver only
3. Sign firmware so open drivers cannot use it
4. Break compatibility regularly
5. Blame the community when things fail

AMD’s approach:

1. Release documentation (eventually)
2. Support open source driver (amdgpu)
3. Release firmware blobs (required, but at least driver is open)
4. Hire developers to work on Mesa

AMD is not perfect. But AMD is not hostile. NVIDIA is hostile.

What Blobs Can Do:

Your WiFi firmware blob has:

• Its own CPU
• Direct memory access (DMA) capability
• Access to all packets before encryption
• The ability to inject packets
• No auditing possible

A compromised WiFi firmware could:

• Exfiltrate data over the air
• Inject malicious packets
• Act as a backdoor undetectable by your OS
• Survive OS reinstallation

This is not theoretical. Broadcom WiFi firmware vulnerabilities have been exploited. The blob is an attack surface your open source kernel cannot protect.

The OpenBSD Approach:

Theo de Raadt’s position: blobs are unacceptable, but sometimes unavoidable.

OpenBSD provides fw_update:

# Download firmware blobs from OpenBSD servers
fw_update

The blobs are:

• Not in the base system
• Not on the install media
• Downloaded separately, explicitly
• Never pretended to be open source

OpenBSD makes you aware: you are loading code you cannot audit. The choice is explicit.

The FreeBSD Approach:

FreeBSD includes many firmware blobs in the linux-firmware port and base:

# In /boot/loader.conf
if_iwlwifi_load="YES"
iwlwifi_fw_load="YES"

# Firmware loads automatically

Convenient. But the blob is there, running on your WiFi chip, unaudited.

The Linux Approach:

Linux has the linux-firmware package — a repository of every blob every vendor provides:

/lib/firmware/
├── intel/
│   └── ibt-*.sfi
├── iwlwifi-*.ucode
├── amdgpu/
│   └── dozens of files
├── nvidia/
│   └── if you're lucky
└── regulatory.db

Hundreds of megabytes of binary code that runs on your hardware. All unaudited. All trusted completely.

The FSF Position:

The Free Software Foundation maintains a list of “free” distributions. To qualify:

• No proprietary firmware in default install
• No tools to easily install proprietary firmware
• No proprietary software recommended

Distributions that qualify: Trisquel, Parabola, PureOS, Guix.

Hardware that works with zero blobs: Almost none. Old ThinkPads with ath9k. Some ARM boards. Rare.

The FSF position is principled. The FSF position is also impractical for most hardware.

CPU Microcode:

Even your CPU runs code you cannot audit:

# Linux
/lib/firmware/intel-ucode/
/lib/firmware/amd-ucode/

# FreeBSD
microcode_update_enable="YES"

Microcode patches are loaded at every boot. They fix CPU bugs. They also run inside your CPU with maximum privilege.

Spectre and Meltdown mitigations were delivered via microcode. The same mechanism could deliver anything else.

You cannot avoid CPU microcode. Your CPU loads it from flash even without OS involvement. The blob is inside the silicon.

The Blob-Free Dream:

Some projects attempt blob-free computing:

Project	Approach
Libreboot	Blob-free firmware (limited hardware)
TALOS II	OpenPOWER with open firmware
Raptor Computing	Owner-controlled firmware
MNT Reform	Open hardware laptop (ARM)
Framework	Not blob-free, but repairable

Truly blob-free computing requires:

• Old hardware (pre-blob WiFi, pre-blob GPU)
• Exotic hardware (POWER9, RISC-V with open implementations)
• Sacrifice (no WiFi, no GPU acceleration, no modern features)

The Reality:

You have two choices:

1. Accept blobs — Use modern hardware, load the firmware, hope it’s not malicious
2. Reject blobs — Use old/exotic hardware, sacrifice features, maintain ideological purity

Most choose option 1. The hardware works. The vulnerabilities are theoretical (until they aren’t).

Our Position:

In Pyongyang, we classify hardware by blob requirements:

Classification	Policy
Critical systems	No network hardware with blobs. Air-gapped.
Network edge	Blobs acceptable. Isolated VLANs.
Research systems	Anything goes. Sandboxed.
Public-facing	Hardened. Blob hardware on separate bus.

We cannot eliminate blobs. We can isolate them. A compromised WiFi blob cannot exfiltrate if the device has no network access.

Defense in depth. Assume the blob is hostile. Plan accordingly.

The Lesson:

Your open source operating system is a castle. The kernel is the wall. The userland is the interior.

The blob is a vendor’s employee living inside your walls, with a key to every room, reporting to someone else.

You cannot evict the blob without losing hardware functionality. You can only watch it, isolate it, and limit what it can access.

Open source is freedom. Blobs are the chains that remain.

Know your blobs. Audit what you can. Isolate what you cannot.

And when you buy hardware, remember: the vendor chose to require a blob. The vendor chose to hide their hardware. The vendor does not trust you.

Return the sentiment.

— Kim Jong Rails, Supreme Leader of the Republic of Derails