Yesterday we discussed the 200KB border wall — why drivers cannot cross operating system boundaries and how vendors exploit this fragmentation. Today we name names.

We start with the worst.

Broadcom.

Not the worst at making chips. Broadcom makes excellent chips. Their WiFi silicon is in millions of laptops. Their Ethernet controllers are in most enterprise servers. Their switch ASICs route traffic across the internet. Their chips are everywhere because their chips are good.

Broadcom is the worst at everything else.

The Acquisition Machine:

Before we discuss drivers, you must understand what Broadcom is. Broadcom is not a chip company. Broadcom is an acquisition engine that happens to make chips.

Year	Acquisition	Price	What Happened After
2015	Broadcom Corporation (by Avago)	$37B	Avago took the Broadcom name
2017	Brocade Communications	$5.9B	Gutted
2018	CA Technologies	$18.9B	Prices raised, innovation stopped
2019	Symantec Enterprise	$10.7B	Prices raised, innovation stopped
2023	VMware	$61B	Prices raised 12x, EU investigation

The pattern is consistent: acquire a company, raise prices, cut staff, reduce support, extract maximum revenue from existing customers who cannot easily migrate away. This is not an accusation. This is their documented business model. Analysts praise it. Shareholders reward it. Customers suffer it.

The VMware acquisition is the masterpiece. Broadcom acquired VMware for $61 billion in November 2023 — the largest enterprise software acquisition in history. Then they eliminated perpetual licenses, collapsed 168 product bundles into 4, and raised prices. Customers reported increases of 8x to 15x. A Dutch government agency saw their annual costs jump from €2.1 million to nearly €4 million — an 85% increase — and took Broadcom to court. A Dutch court ordered Broadcom to continue support during migration.

The European Commission opened an investigation. The European Cloud Competition Observatory gave Broadcom a red status — their most critical rating — declaring that Broadcom’s licensing model “appears to rely on practices that breach EU competition regulations.”

This is the company that makes your WiFi chip. This is the company whose firmware runs on your laptop’s wireless radio. This is the entity you trust with the silicon that handles every packet between your machine and the internet.

The WiFi Driver Saga:

For the first several years of Broadcom WiFi chips on Linux, there was no driver. Not a bad driver. Not a limited driver. No driver. Broadcom provided nothing. If you wanted WiFi on Linux with a Broadcom chip, you used a reverse-engineered driver built by volunteers who extracted behavior from the proprietary Windows driver.

The timeline:

Year	Event
Early 2000s	Broadcom WiFi chips ship with no Linux driver
~2006	b43 reverse-engineered driver enters Linux 2.6.24
2008	Broadcom releases proprietary wl (broadcom-sta) driver
2010	Broadcom releases open-source brcm80211 driver
2011	brcm80211 split into brcmsmac (SoftMAC) and brcmfmac (FullMAC)
2026	FreeBSD still has no native Broadcom WiFi for modern chips

Let us examine each step.

The b43 driver was built by reverse engineering. Volunteers studied the hardware, analyzed the proprietary Windows driver, and wrote a Linux driver from scratch. Broadcom contributed nothing to this effort. They also did not prevent it — not out of goodwill, but because they could not.

The wl driver (also called broadcom-sta) was Broadcom’s answer to community pressure. It was proprietary, restrictively licensed, and used its own MAC layer instead of the kernel’s mac80211 stack. This means it bypassed the standard Linux wireless infrastructure entirely, expanding the attack surface and making integration with standard tools difficult. It worked for older chips. It was never properly maintained. As of recent kernels (4.7+), it requires community patches to compile at all.

The brcm80211 release in 2010 was the first real open-source effort. Broadcom released a driver that worked with the kernel’s standard interfaces. It was later split into brcmsmac for PCIe SoftMAC devices and brcmfmac for SDIO/USB FullMAC devices. This was progress.

But the firmware that brcmfmac requires is not fully open-source and not always licensed for redistribution. The driver is open. The firmware it depends on is not. You have open-source code that cannot function without proprietary blobs that the vendor may or may not allow you to distribute.

The GPL Incident:

In 2007, the communities of Linux and OpenBSD nearly went to war over Broadcom.

The Linux bcm43xx driver had been painstakingly reverse-engineered by volunteers and licensed under GPLv2. An OpenBSD developer, working on a BSD-licensed bcw driver, was found to have copied code from the Linux driver — stripping the GPL license headers in the process.

The Linux developers confronted the OpenBSD project. The mailing lists exploded. The bcm43xx developers had specifically discussed dual-licensing in 2005 to allow BSD to benefit, but decided against it. The GPL code was GPL-only.

The resolution: the OpenBSD developer abandoned the bcw project entirely. The driver died. OpenBSD users got nothing.

Broadcom caused this. Not directly — they did not write either driver. But their refusal to provide documentation or open-source drivers forced two communities to reverse-engineer the same hardware independently, and when one community’s code contaminated the other’s, the license wall destroyed years of work.

The Security Record:

In 2017, security researcher Nitay Artenstein discovered BroadPwn (CVE-2017-9417) — a critical remote code execution vulnerability in Broadcom’s BCM43xx WiFi chipset family.

The findings:

• Fully remote: no user interaction required
• Code execution on the main application processor: not just the WiFi chip — the entire device
• No ASLR: Address Space Layout Randomization was not implemented in the WiFi firmware
• RWX everywhere: the entire RAM of the WiFi chip was readable, writable, and executable — no memory protection of any kind
• Affected devices: iPhones, Samsung flagships, HTC, LG, Nexus, and practically every Android device with Broadcom WiFi

The WiFi firmware on millions of phones had no memory protection. Any code could be read, written, or executed anywhere in the chip’s memory. This is not a bug. This is the absence of every security practice developed in the last thirty years.

Apple patched iOS. Google patched Android. Broadcom continued selling chips.

Every WiFi chip is a FullMAC computer inside your computer, running firmware you cannot audit. Broadcom’s firmware was running with the security posture of a 1985 DOS machine. On every phone in your pocket.

The BSD Situation:

As of February 2026, FreeBSD has no native driver for modern Broadcom WiFi chips.

Let that sink in. FreeBSD — the operating system that Sony forked for the PlayStation 4 and PlayStation 5. The operating system that Netflix uses to serve a third of internet traffic. The operating system with a 30-year history. It cannot connect to WiFi if you have a modern Broadcom chip.

The Linux brcmfmac driver exists. It is GPL-licensed. FreeBSD cannot use it directly — different kernel API, different license. The linuxkpi compatibility layer could theoretically bridge the gap, but nobody had done the work.

Broadcom makes billions in revenue. They employ thousands of engineers. They could provide a FreeBSD driver in a week. They choose not to.

The Ethernet Side:

Broadcom’s hostility extends beyond WiFi. Their Ethernet drivers (tg3, bnx2) have their own history:

• The tg3 driver reduced an NVRAM command timeout from 100ms to 1ms, which was too short for write operations and could leave the network card in an unusable state — preventing the server from booting
• The bnx2 driver crashed when receiving jumbo packets mixed with firmware management packets because the firmware DMA’d to the wrong address
• Missing firmware files during installation caused Broadcom Ethernet hardware to fail to initialize — on servers, in production, during deployment

These are not obscure edge cases. These are enterprise Ethernet controllers in IBM BladeCenter and HP ProLiant servers. The hardware that runs datacenters.

The Raspberry Pi Connection:

Every Raspberry Pi uses a Broadcom SoC. The Raspberry Pi Foundation has a long relationship with Broadcom — Eben Upton, the founder, worked at Broadcom before starting the foundation.

The GPU driver for Broadcom’s VideoCore was proprietary for years. The Raspberry Pi was marketed as an educational and open-source platform while running on a chip whose GPU documentation was locked behind NDAs. Mesa open-source drivers eventually arrived, but the early years of “open-source education platform with a proprietary GPU” was a contradiction that the community noted repeatedly.

The Pattern:

Broadcom’s behavior across every domain is consistent:

1. Make excellent hardware
2. Provide minimal software support
3. Favor proprietary drivers over open-source
4. Abandon older hardware without notice
5. Acquire companies and extract revenue
6. Let the community do the maintenance work for free

They do not need to cooperate. Their chips are in too many devices. If your laptop has Broadcom WiFi and you install Linux, you will make it work — you will find the firmware, load the module, troubleshoot the conflicts. You have no alternative. The chip is soldered to the board.

This is the leverage. Not technical superiority. Market position. When your silicon is in every second laptop, cooperation is optional.

The Lesson:

In the border wall post, I described the fragmentation of driver ecosystems as a structural problem — incompatible ABIs, incompatible licenses, incompatible incentives.

Broadcom is not a structural problem. Broadcom is a policy choice. They choose not to provide open documentation. They choose not to provide BSD drivers. They choose not to implement basic memory protection in their WiFi firmware. They choose to acquire companies and raise prices until courts intervene.

The chips are excellent. The company is hostile. These two facts coexist because the market rewards silicon quality and does not punish ecosystem hostility. Broadcom will continue to be hostile because hostility is profitable.

In the Republic of Derails, we also have a single vendor for all hardware. But our vendor provides drivers for every operating system we run. Granted, we run one operating system. But the point stands.

Next time we will discuss a vendor with a different approach. Not because they are kind — because they learned that cooperation is cheaper than contempt.

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