boltd(8) - f35

1BOLTD(8)                          bolt Manual                         BOLTD(8)
2
3
4

NAME

6       boltd - thunderbolt device managing system daemon
7

SYNOPSIS

9       boltd [OPTIONS]
10

DESCRIPTION

12       boltd is the thunderbolt device manager daemon. Its goal is to enable
13       the secure and convenient use of thunderbolt devices by using the
14       security features of modern thunderbolt controllers. It provides the
15       org.freedesktop.bolt name on the system bus. boltd is autostarted via
16       systemd/udev if a thunderbolt device is connected.
17
18       The thunderbolt I/O technology works by bridging PCIe between the
19       controllers on each end of the connection, which in turn means that
20       devices connected via Thunderbolt are ultimately connected via PCIe.
21       Therefore thunderbolt can achieve very high connection speeds, fast
22       enough to even drive external graphics cards. The downside is that it
23       also makes certain attacks possible. To mitigate these security
24       problems, the latest version — known as Thunderbolt 3 — supports
25       different security levels:
26
27       none
28           No security. The behavior is identical to previous Thunderbolt
29           versions.
30
31       dponly
32           No PCIe tunnels are created at all, but DisplayPort tunnels are
33           allowed and will work.
34
35       user
36           Connected devices must be authorized by the user. Only then will
37           the PCIe tunnels be activated.
38
39       secure
40           Basically the same as user mode, but additionally a key will be
41           written to the device the first time the device is connected. This
42           key will then be used to verify the identity of the connected
43           device.
44
45       The primary task of boltd is to authorize thunderbolt peripherals if
46       the security level is either user or secure. It provides a D-Bus API to
47       list devices, enroll them (authorize and store them in the local
48       database) and forget them again (remove previously enrolled devices).
49       It also emits signals if new devices are connected (or removed). During
50       enrollment devices can be set to be automatically authorized as soon as
51       they are connected. A command line tool, called boltctl(1), can be used
52       to control the daemon and perform all the above mentioned tasks.
53
54       The pre-boot access control list (BootACL) feature is active when
55       supported by the firmware and when boltd is running on a new enough
56       Linux kernel (>= 4.17). The BootACL is a list of UUIDs, that can be
57       written to the thunderbolt controller. If enabled in the BIOS, all
58       devices in that list will be authorized by the firmware during
59       pre-boot, which means these devices can be used in the BIOS setup and
60       also during Linux early boot. NB: no device verification is done, even
61       when the security level is set to secure mode in the BIOS, i.e. the
62       maximal effective security level for devices in the BootACL is only
63       user. If BootACL support is present, all new devices will be
64       automatically added. Devices that are forgotten (removed from boltd)
65       will also be removed from the BootACL. When a controller is offline,
66       changes to the BootACL will be written to a journal and synchronized
67       back when the controller is online again.
68
69       IOMMU support: if the hardware and firmware support using the
70       input–output memory management unit (IOMMU) to restrict direct memory
71       access to certain safe regions, boltd will detect that feature and
72       change its behavior: As long as iommu support is active, as indicated
73       by the iommu_dma_protection sysfs attribute of the domain controller,
74       new devices will be automatically enrolled with the iommu policy and
75       existing devices with iommu (or auto) policy will be automatically
76       authorized by boltd without any user interaction. When iommu is not
77       active, devices that were enrolled with the iommu policy will not be
78       authorized automatically. The status of iommu support can be inspected
79       by using boltctl domains.
80

OPTIONS

82       -h, --help
83           Prints a short help text and exits.
84
85       --version
86           Shows the version number and exits.
87
88       -r, --replace
89           Replace the currently running boltd instance.
90
91       --journal
92           Force logging to the journal.
93
94       -v, --verbose
95           Print debug output.
96

ENVIRONMENT

98       RUNTIME_DIRECTORY
99           Specifies the path where the daemon stores data that only has to
100           live as long as the current boot. Will be set automatically when
101           started via systemd (>= 240). If not set the default path for
102           runtime data is /run/boltd.
103
104       STATE_DIRECTORY
105           Specifies the path where the daemon stores device information,
106           including the keys used for authorization. Overwrites the path that
107           was set at compile time. Will be set automatically when started via
108           systemd (>= 240).
109
110       BOLT_DBPATH
111           Same as STATE_DIRECTORY but takes precedence over that, if set.
112

EXIT STATUS

114       On success 0 is returned, a non-zero failure code otherwise.
115

AUTHOR

117       Written by Christian Kellner <ckellner@redhat.com>.
118