BOLTD(8)

💅 BOLTD(8) — bolt Manual 💅

okay bestie, sit down, hydrate, because we're talking about boltd, from the bolt manual, section 8 (that's the big-girl system-administration section, we love her).

---

✨ NAME ✨

boltd — the thunderbolt device managing system daemon 🦋

---

✨ SYNOPSIS ✨

boltd [OPTIONS]

---

✨ DESCRIPTION ✨

so boltd is literally the thunderbolt device manager daemon. her whole goal? enabling the secure AND convenient use of thunderbolt devices by using the security features of modern thunderbolt controllers. she provides the org.freedesktop.bolt name on the system bus, and she gets autostarted via systemd/udev whenever a thunderbolt device is connected. main character energy, no cap. 👑

okay so the thunderbolt I/O technology works by bridging PCIe between the controllers on each end of the connection, which means devices connected via Thunderbolt are ultimately connected via PCIe. the result? thunderbolt can hit very high connection speeds, fast enough to even drive external graphics cards. slay. but the downside is that it also makes certain attacks possible 😭. to mitigate these security problems, the latest version — known as Thunderbolt 3 — supports different security levels:

• none — no security, bestie. the behavior is identical to previous Thunderbolt versions. it's giving chaos.
• dponly — no PCIe tunnels are created at all, but DisplayPort tunnels are allowed and will work. 🖥️
• user — connected devices must be authorized by the user. only then will the PCIe tunnels be activated.
• secure — basically the same as user mode, but additionally a key will be written to the device the first time the device is connected. this key will then be used to verify the identity of the connected device. 🔐
• usbonly — one PCIe tunnel is created to a usb controller in a thunderbolt dock; no other downstream PCIe tunnels are authorized (needs 4.17 kernel and recent hardware).

the primary task of boltd is to authorize thunderbolt peripherals if the security level is either user or secure. she provides a D-Bus API to list devices, enroll them (authorize and store them in the local database) and forget them again (remove previously enrolled devices). she also emits signals if new devices are connected (or removed). during enrollment, devices can be set to be automatically authorized as soon as they are connected. and there's a command line tool called boltctl(1) that you can use to control the daemon and perform all the above mentioned tasks. periodt. 💅

the pre-boot access control list (BootACL) feature is active when supported by the firmware and when boltd is running on a new enough Linux kernel (>= 4.17). the BootACL is a list of UUIDs that can be written to the thunderbolt controller. if enabled in the BIOS, all devices in that list will be authorized by the firmware during pre-boot, which means these devices can be used in the BIOS setup and also during Linux early boot. NB: no device verification is done, even when the security level is set to secure mode in the BIOS, i.e. the maximal effective security level for devices in the BootACL is only user. if BootACL support is present, all new devices will be automatically added. devices that are forgotten (removed from boltd) will also be removed from the BootACL. when a controller is offline, changes to the BootACL will be written to a journal and synchronized back when the controller is online again. 🗂️

IOMMU support: if the hardware and firmware support using the input–output memory management unit (IOMMU) to restrict direct memory access to certain safe regions, boltd will detect that feature and change its behavior. as long as iommu support is active — as indicated by the iommu_dma_protection sysfs attribute of the domain controller — new devices will be automatically enrolled with the iommu policy and existing devices with iommu (or auto) policy will be automatically authorized by boltd without any user interaction. when iommu is not active, devices that were enrolled with the iommu policy will not be authorized automatically. the status of iommu support can be inspected by using boltctl domains. 🌈

---

✨ OPTIONS ✨

• -h, --help — prints a short help text and exits. the "wait what does this do again" button 🫶
• --version — shows the version number and exits.
• -r, --replace — replaces the currently running boltd instance. out with the old, in with the new 💅
• --journal — forces logging to the journal.
• -v, --verbose — prints debug output. for when you need to see everything 🔍

---

✨ ENVIRONMENT ✨

• RUNTIME_DIRECTORY — specifies the path where the daemon stores data that only has to live as long as the current boot. will be set automatically when started via systemd (>= 240). if not set, the default path for runtime data is /run/boltd.
• STATE_DIRECTORY — specifies the path where the daemon stores device information, including the keys used for authorization. overwrites the path that was set at compile time. will be set automatically when started via systemd (>= 240).
• BOLT_DBPATH — same as STATE_DIRECTORY but takes precedence over that, if set. she said "I'm the boss now" 😌

---

✨ EXIT STATUS ✨

on success 0 is returned, a non-zero failure code otherwise. that's it, that's the whole vibe check. ✅

---

✨ AUTHOR ✨

written by Christian Kellner <ckellner@redhat.com>. icon, legend, ate. 👑

---

✨ SEE ALSO ✨

boltctl(1) — go say hi to her sister 🦋

---

and that's the whole page bestie, no notes 💖 this was bolt 0.9.11, dated 04/01/2026, straight from the bolt Manual. go authorize something safely, ily, byeee 🎀✨