USB-C negotiates.

Thunderbolt negotiates and then invites PCIe into the room.

That is the escalation.

By the time users say, “it’s just a dock,” the machine may already be deciding whether an external device gets:

• DisplayPort tunnels
• PCIe tunnels
• DMA-capable attachment
• firmware-level authorization
• access under IOMMU protection or without it

This is why Thunderbolt never belonged in the category of “convenient port.”

It belonged in the category of external hardware with internal consequences.

BSD does not make that consequence disappear. If the platform exposes Thunderbolt, the firmware and DMA boundary still matter, whether the kernel is Linux or not.

I. Why Thunderbolt Is Different

The critical architectural fact is simple:

Thunderbolt can tunnel PCI Express and DisplayPort over an external cable.

That makes it powerful. It also makes it dangerous in exactly the way power implies.

An external PCIe-capable path is not morally equivalent to plugging in a keyboard. It can expose the system to DMA-capable devices if protections and policy are weak or absent.

That is why the firmware story matters so much.

II. The Old Security Model Was Basically Border Control

The Linux Thunderbolt documentation says the quiet part out loud: connected Thunderbolt devices can be DMA masters and read host memory without the CPU or OS knowing, absent appropriate protection. The same docs define several security levels that firmware can expose:

Security level	Meaning
none	devices connect automatically
user	user approval required before PCIe tunnels are created
secure	stronger device approval with saved-key challenge flow
dponly	DisplayPort/USB only, no PCIe tunneling

This is not an operating system preference panel pretending to be security. This is the firmware deciding what kind of civilization the port belongs to.

If the system is in none, the regime is permissive. If it is in user or secure, the regime admits that external PCIe is a political event.

III. The IOMMU Changed the Argument, Not the Stakes

Later systems gained IOMMU-backed DMA protection, and both Linux and Microsoft document the shift clearly.

Linux now exposes whether IOMMU DMA protection is active for the Thunderbolt domain. Microsoft describes Kernel DMA Protection as using the IOMMU to prevent external DMA-capable peripherals from touching memory outside assigned regions.

That means the modern security story is no longer only “authorize or block the device.”

It is:

• authorize or block
• and, if allowed, isolate DMA properly

Era	Main defense model	Practical weakness
Early Thunderbolt	firmware security levels, manual authorization	devices could still be dangerously trusted without memory isolation
IOMMU-aware era	DMA remapping + policy + authorization	requires firmware, platform, and driver stack to all behave correctly

This is progress. It is also more bureaucracy.

The Supreme Leader approves the bureaucracy because external PCIe without boundaries is just optimism wearing a cable.

IV. Firmware Still Runs the Border

Even with IOMMU protection, a great deal of Thunderbolt behavior still sits in firmware:

• host controller NVM
• device NVM
• retimer firmware
• authorization state
• tunnel creation policy

The current Linux Thunderbolt documentation explicitly includes NVM upgrade flows for host, device, and retimer firmware because so much functionality lives there.

That line is more important than it looks.

It means Thunderbolt bugs are not merely software bugs or driver bugs. They are often firmware bugs in the machinery that decides what the cable is allowed to become.

V. What the User Thinks vs What the Port Is Doing

A user sees:

• one cable
• one dock
• one monitor setup

The machine is actually working through something closer to this:

USB-C receptacle
  -> Thunderbolt controller firmware
  -> security level / authorization policy
  -> PCIe and DisplayPort tunnel decisions
  -> IOMMU/DMA protection state
  -> host/device/retimer firmware interactions

This is why Thunderbolt failures feel weird.

Symptoms are often:

• display works, storage does not
• storage works, Ethernet does not
• dock works only after login
• one OS version works, another refuses the device
• firmware update changes behavior more than driver reinstall ever did

These are not random. These are layered policy outcomes.

VI. Why Operating Systems Had to Admit the Threat Model

Microsoft’s own security guidance states the core concern plainly: hot-pluggable PCIe-style peripherals such as Thunderbolt can perform DMA, and Kernel DMA Protection exists to control that. Microsoft also notes that older buses such as FireWire remain outside this protection model.

Intel’s own Thunderbolt 4 security material likewise centers VT-d-based DMA protection as a core security property.

This is the part people miss:

the vendor messaging stopped treating Thunderbolt security as optional polish. It became a first-class architectural property.

Because the old story had already taught the lesson.

VII. Retimers: Because One Firmware Domain Was Not Enough

Thunderbolt at modern speeds also pulls in retimers and similar signal-conditioning hardware.

That means one external port may depend on multiple firmware-governed components behaving correctly:

• host controller firmware
• connected-device firmware
• retimer firmware

If you wanted a simple cable, this will disappoint you. If you wanted a small distributed state machine attached to your motherboard edge, congratulations.

VIII. The Real Story (Suppressed)

Officially, Thunderbolt is a high-speed I/O technology.

Unofficially, it is a diplomatic channel through which external hardware requests temporary immunity from the normal suspicion owed to outsiders.

The firmware inspects the passport. The security level defines the border regime. The IOMMU determines how far the visitor may travel inside the republic.

Without that structure, Thunderbolt is not “fast docking.” It is external PCIe wandering your capital without escort.

The Supreme Leader finds this unacceptable except under documented procedure.

The Decree

Thunderbolt firmware matters because the port is not just a transport. It is a trust boundary with tunneling privileges.

If you want Thunderbolt systems to behave, you need all of these aligned:

• sane firmware security levels
• current host/device/retimer NVM where relevant
• functioning IOMMU-based DMA protection
• operating system policy that understands the bus it is inheriting

When this works, Thunderbolt feels miraculous. One cable, many devices, high speed, adult behavior.

When it fails, you discover that your “monitor dock” was actually a border-crossing apparatus for PCIe, DMA, and firmware state.

And that is why Thunderbolt is the natural successor to FireWire:

the same appetite for power, with better paperwork.

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