요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.
1. 요약·해설
원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.
2. 영어 원문 전체
번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.
원문 전체 펼치기
.. SPDX-License-Identifier: GPL-2.0
======================
USB4 and Thunderbolt
======================
USB4 is the public specification based on Thunderbolt 3 protocol with
some differences at the register level among other things. Connection
manager is an entity running on the host router (host controller)
responsible for enumerating routers and establishing tunnels. A
connection manager can be implemented either in firmware or software.
Typically PCs come with a firmware connection manager for Thunderbolt 3
and early USB4 capable systems. Apple systems on the other hand use
software connection manager and the later USB4 compliant devices follow
the suit.
The Linux Thunderbolt driver supports both and can detect at runtime which
connection manager implementation is to be used. To be on the safe side the
software connection manager in Linux also advertises security level
``user`` which means PCIe tunneling is disabled by default. The
documentation below applies to both implementations with the exception that
the software connection manager only supports ``user`` security level and
is expected to be accompanied with an IOMMU based DMA protection.
Security levels and how to use them
-----------------------------------
The interface presented here is not meant for end users. Instead there
should be a userspace tool that handles all the low-level details, keeps
a database of the authorized devices and prompts users for new connections.
More details about the sysfs interface for Thunderbolt devices can be
found in Documentation/ABI/testing/sysfs-bus-thunderbolt.
Those users who just want to connect any device without any sort of
manual work can add following line to
``/etc/udev/rules.d/99-local.rules``::
ACTION=="add", SUBSYSTEM=="thunderbolt", ATTR{authorized}=="0", ATTR{authorized}="1"
This will authorize all devices automatically when they appear. However,
keep in mind that this bypasses the security levels and makes the system
vulnerable to DMA attacks.
Starting with Intel Falcon Ridge Thunderbolt controller there are 4
security levels available. Intel Titan Ridge added one more security level
(usbonly). The reason for these is the fact that the connected devices can
be DMA masters and thus read contents of the host memory without CPU and OS
knowing about it. There are ways to prevent this by setting up an IOMMU but
it is not always available for various reasons.
Some USB4 systems have a BIOS setting to disable PCIe tunneling. This is
treated as another security level (nopcie).
The security levels are as follows:
none
All devices are automatically connected by the firmware. No user
approval is needed. In BIOS settings this is typically called
*Legacy mode*.
user
User is asked whether the device is allowed to be connected.
Based on the device identification information available through
``/sys/bus/thunderbolt/devices``, the user then can make the decision.
In BIOS settings this is typically called *Unique ID*.
secure
User is asked whether the device is allowed to be connected. In
addition to UUID the device (if it supports secure connect) is sent
a challenge that should match the expected one based on a random key
written to the ``key`` sysfs attribute. In BIOS settings this is
typically called *One time saved key*.
dponly
The firmware automatically creates tunnels for Display Port and
USB. No PCIe tunneling is done. In BIOS settings this is
typically called *Display Port Only*.
usbonly
The firmware automatically creates tunnels for the USB controller and
Display Port in a dock. All PCIe links downstream of the dock are
removed.
nopcie
PCIe tunneling is disabled/forbidden from the BIOS. Available in some
USB4 systems.
The current security level can be read from
``/sys/bus/thunderbolt/devices/domainX/security`` where ``domainX`` is
the Thunderbolt domain the host controller manages. There is typically
one domain per Thunderbolt host controller.
If the security level reads as ``user`` or ``secure`` the connected
device must be authorized by the user before PCIe tunnels are created
(e.g the PCIe device appears).
Each Thunderbolt device plugged in will appear in sysfs under
``/sys/bus/thunderbolt/devices``. The device directory carries
information that can be used to identify the particular device,
including its name and UUID.
Authorizing devices when security level is ``user`` or ``secure``
-----------------------------------------------------------------
When a device is plugged in it will appear in sysfs as follows::
/sys/bus/thunderbolt/devices/0-1/authorized - 0
/sys/bus/thunderbolt/devices/0-1/device - 0x8004
/sys/bus/thunderbolt/devices/0-1/device_name - Thunderbolt to FireWire Adapter
/sys/bus/thunderbolt/devices/0-1/vendor - 0x1
/sys/bus/thunderbolt/devices/0-1/vendor_name - Apple, Inc.
/sys/bus/thunderbolt/devices/0-1/unique_id - e0376f00-0300-0100-ffff-ffffffffffff
The ``authorized`` attribute reads 0 which means no PCIe tunnels are
created yet. The user can authorize the device by simply entering::
# echo 1 > /sys/bus/thunderbolt/devices/0-1/authorized
This will create the PCIe tunnels and the device is now connected.
If the device supports secure connect, and the domain security level is
set to ``secure``, it has an additional attribute ``key`` which can hold
a random 32-byte value used for authorization and challenging the device in
future connects::
/sys/bus/thunderbolt/devices/0-3/authorized - 0
/sys/bus/thunderbolt/devices/0-3/device - 0x305
/sys/bus/thunderbolt/devices/0-3/device_name - AKiTiO Thunder3 PCIe Box
/sys/bus/thunderbolt/devices/0-3/key -
/sys/bus/thunderbolt/devices/0-3/vendor - 0x41
/sys/bus/thunderbolt/devices/0-3/vendor_name - inXtron
/sys/bus/thunderbolt/devices/0-3/unique_id - dc010000-0000-8508-a22d-32ca6421cb16
Notice the key is empty by default.
If the user does not want to use secure connect they can just ``echo 1``
to the ``authorized`` attribute and the PCIe tunnels will be created in
the same way as in the ``user`` security level.
If the user wants to use secure connect, the first time the device is
plugged a key needs to be created and sent to the device::
# key=$(openssl rand -hex 32)
# echo $key > /sys/bus/thunderbolt/devices/0-3/key
# echo 1 > /sys/bus/thunderbolt/devices/0-3/authorized
Now the device is connected (PCIe tunnels are created) and in addition
the key is stored on the device NVM.
Next time the device is plugged in the user can verify (challenge) the
device using the same key::
# echo $key > /sys/bus/thunderbolt/devices/0-3/key
# echo 2 > /sys/bus/thunderbolt/devices/0-3/authorized
If the challenge the device returns back matches the one we expect based
on the key, the device is connected and the PCIe tunnels are created.
However, if the challenge fails no tunnels are created and error is
returned to the user.
If the user still wants to connect the device they can either approve
the device without a key or write a new key and write 1 to the
``authorized`` file to get the new key stored on the device NVM.
De-authorizing devices
----------------------
It is possible to de-authorize devices by writing ``0`` to their
``authorized`` attribute. This requires support from the connection
manager implementation and can be checked by reading domain
``deauthorization`` attribute. If it reads ``1`` then the feature is
supported.
When a device is de-authorized the PCIe tunnel from the parent device
PCIe downstream (or root) port to the device PCIe upstream port is torn
down. This is essentially the same thing as PCIe hot-remove and the PCIe
toplogy in question will not be accessible anymore until the device is
authorized again. If there is storage such as NVMe or similar involved,
there is a risk for data loss if the filesystem on that storage is not
properly shut down. You have been warned!
DMA protection utilizing IOMMU
------------------------------
Recent systems from 2018 and forward with Thunderbolt ports may natively
support IOMMU. This means that Thunderbolt security is handled by an IOMMU
so connected devices cannot access memory regions outside of what is
allocated for them by drivers. When Linux is running on such system it
automatically enables IOMMU if not enabled by the user already. These
systems can be identified by reading ``1`` from
``/sys/bus/thunderbolt/devices/domainX/iommu_dma_protection`` attribute.
The driver does not do anything special in this case but because DMA
protection is handled by the IOMMU, security levels (if set) are
redundant. For this reason some systems ship with security level set to
``none``. Other systems have security level set to ``user`` in order to
support downgrade to older OS, so users who want to automatically
authorize devices when IOMMU DMA protection is enabled can use the
following ``udev`` rule::
ACTION=="add", SUBSYSTEM=="thunderbolt", ATTRS{iommu_dma_protection}=="1", ATTR{authorized}=="0", ATTR{authorized}="1"
Upgrading NVM on Thunderbolt device, host or retimer
----------------------------------------------------
Since most of the functionality is handled in firmware running on a
host controller or a device, it is important that the firmware can be
upgraded to the latest where possible bugs in it have been fixed.
Typically OEMs provide this firmware from their support site.
There is also a central site which has links where to download firmware
for some machines:
`Thunderbolt Updates <https://thunderbolttechnology.net/updates>`_
Before you upgrade firmware on a device, host or retimer, please make
sure it is a suitable upgrade. Failing to do that may render the device
in a state where it cannot be used properly anymore without special
tools!
Host NVM upgrade on Apple Macs is not supported.
Once the NVM image has been downloaded, you need to plug in a
Thunderbolt device so that the host controller appears. It does not
matter which device is connected (unless you are upgrading NVM on a
device - then you need to connect that particular device).
Note an OEM-specific method to power the controller up ("force power") may
be available for your system in which case there is no need to plug in a
Thunderbolt device.
After that we can write the firmware to the non-active parts of the NVM
of the host or device. As an example here is how Intel NUC6i7KYK (Skull
Canyon) Thunderbolt controller NVM is upgraded::
# dd if=KYK_TBT_FW_0018.bin of=/sys/bus/thunderbolt/devices/0-0/nvm_non_active0/nvmem
Once the operation completes we can trigger NVM authentication and
upgrade process as follows::
# echo 1 > /sys/bus/thunderbolt/devices/0-0/nvm_authenticate
If no errors are returned, the host controller shortly disappears. Once
it comes back the driver notices it and initiates a full power cycle.
After a while the host controller appears again and this time it should
be fully functional.
We can verify that the new NVM firmware is active by running the following
commands::
# cat /sys/bus/thunderbolt/devices/0-0/nvm_authenticate
0x0
# cat /sys/bus/thunderbolt/devices/0-0/nvm_version
18.0
If ``nvm_authenticate`` contains anything other than 0x0 it is the error
code from the last authentication cycle, which means the authentication
of the NVM image failed.
Note names of the NVMem devices ``nvm_activeN`` and ``nvm_non_activeN``
depend on the order they are registered in the NVMem subsystem. N in
the name is the identifier added by the NVMem subsystem.
Upgrading on-board retimer NVM when there is no cable connected
---------------------------------------------------------------
If the platform supports, it may be possible to upgrade the retimer NVM
firmware even when there is nothing connected to the USB4
ports. When this is the case the ``usb4_portX`` devices have two special
attributes: ``offline`` and ``rescan``. The way to upgrade the firmware
is to first put the USB4 port into offline mode::
# echo 1 > /sys/bus/thunderbolt/devices/0-0/usb4_port1/offline
This step makes sure the port does not respond to any hotplug events,
and also ensures the retimers are powered on. The next step is to scan
for the retimers::
# echo 1 > /sys/bus/thunderbolt/devices/0-0/usb4_port1/rescan
This enumerates and adds the on-board retimers. Now retimer NVM can be
upgraded in the same way than with cable connected (see previous
section). However, the retimer is not disconnected as we are offline
mode) so after writing ``1`` to ``nvm_authenticate`` one should wait for
5 or more seconds before running rescan again::
# echo 1 > /sys/bus/thunderbolt/devices/0-0/usb4_port1/rescan
This point if everything went fine, the port can be put back to
functional state again::
# echo 0 > /sys/bus/thunderbolt/devices/0-0/usb4_port1/offline
Upgrading NVM when host controller is in safe mode
--------------------------------------------------
If the existing NVM is not properly authenticated (or is missing) the
host controller goes into safe mode which means that the only available
functionality is flashing a new NVM image. When in this mode, reading
``nvm_version`` fails with ``ENODATA`` and the device identification
information is missing.
To recover from this mode, one needs to flash a valid NVM image to the
host controller in the same way it is done in the previous chapter.
Tunneling events
----------------
The driver sends ``KOBJ_CHANGE`` events to userspace when there is a
tunneling change in the ``thunderbolt_domain``. The notification carries
following environment variables::
TUNNEL_EVENT=<EVENT>
TUNNEL_DETAILS=0:12 <-> 1:20 (USB3)
Possible values for ``<EVENT>`` are:
activated
The tunnel was activated (created).
changed
There is a change in this tunnel. For example bandwidth allocation was
changed.
deactivated
The tunnel was torn down.
low bandwidth
The tunnel is not getting optimal bandwidth.
insufficient bandwidth
There is not enough bandwidth for the current tunnel requirements.
The ``TUNNEL_DETAILS`` is only provided if the tunnel is known. For
example, in case of Firmware Connection Manager this is missing or does
not provide full tunnel information. In case of Software Connection Manager
this includes full tunnel details. The format currently matches what the
driver uses when logging. This may change over time.
Networking over Thunderbolt cable
---------------------------------
Thunderbolt technology allows software communication between two hosts
connected by a Thunderbolt cable.
It is possible to tunnel any kind of traffic over a Thunderbolt link but
currently we only support Apple ThunderboltIP protocol.
If the other host is running Windows or macOS, the only thing you need to
do is to connect a Thunderbolt cable between the two hosts; the
``thunderbolt-net`` driver is loaded automatically. If the other host is
also Linux you should load ``thunderbolt-net`` manually on one host (it
does not matter which one)::
# modprobe thunderbolt-net
This triggers module load on the other host automatically. If the driver
is built-in to the kernel image, there is no need to do anything.
The driver will create one virtual ethernet interface per Thunderbolt
port which are named like ``thunderbolt0`` and so on. From this point
you can either use standard userspace tools like ``ifconfig`` to
configure the interface or let your GUI handle it automatically.
Forcing power
-------------
Many OEMs include a method that can be used to force the power of a
Thunderbolt controller to an "On" state even if nothing is connected.
If supported by your machine this will be exposed by the WMI bus with
a sysfs attribute called "force_power", see
Documentation/ABI/testing/sysfs-platform-intel-wmi-thunderbolt for details.
Note: it's currently not possible to query the force power state of a platform.
3. 한국어 전문 번역
영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.
USB4 and Thunderbolt
1-23원문 SPDX license identifier는 `GPL-2.0`입니다.
USB4는 Thunderbolt 3 protocol에 기반한 공개 specification이며 register level 등에 차이가 있습니다. host router(host controller)의 connection manager는 router enumeration과 tunnel 설정을 담당하며 firmware 또는 software로 구현할 수 있습니다.
일반 PC의 Thunderbolt 3와 초기 USB4 system은 firmware connection manager를, Apple system과 이후 USB4 compliant device는 software manager를 사용합니다. Linux Thunderbolt driver는 둘을 runtime에 감지합니다.
Linux software manager는 안전을 위해 security level `user`를 advertise하여 PCIe tunneling을 기본 비활성화합니다. 아래 설명은 둘 모두에 적용되지만 software manager는 `user`만 지원하며 IOMMU-based DMA protection과 함께 사용할 것으로 기대합니다.
Security levels and how to use them
24-100이 sysfs interface는 end user용이 아닙니다. low-level detail과 authorized device database, 새 connection prompt를 처리하는 userspace tool이 있어야 합니다. 자세한 interface는 `Documentation/ABI/testing/sysfs-bus-thunderbolt`를 참조하십시오.
모든 device를 수동 작업 없이 연결하려면 `/etc/udev/rules.d/99-local.rules`에 다음 rule을 넣을 수 있지만 security level을 우회해 DMA attack에 취약해집니다.
ACTION=="add", SUBSYSTEM=="thunderbolt", ATTR{authorized}=="0", ATTR{authorized}="1"Falcon Ridge controller부터 네 security level이 있고 Titan Ridge가 `usbonly`를 추가했습니다. connected device는 CPU와 OS가 모르게 host memory를 읽는 DMA master가 될 수 있어 이런 정책이 필요하며 IOMMU가 항상 가능한 것은 아닙니다. 일부 USB4 BIOS의 PCIe tunneling 비활성화는 `nopcie` level로 취급합니다.
| level | 동작과 BIOS 명칭 |
|---|---|
| none | firmware가 모든 device를 자동 연결. approval 불필요. 보통 Legacy mode |
| user | `/sys/bus/thunderbolt/devices` identification으로 사용자가 허용 여부 결정. 보통 Unique ID |
| secure | UUID와 `key` attribute에 쓴 random key 기반 challenge를 함께 검증. 보통 One time saved key |
| dponly | DisplayPort와 USB tunnel만 자동 생성하고 PCIe는 생성하지 않음. Display Port Only |
| usbonly | dock의 USB controller와 DisplayPort tunnel을 만들고 downstream PCIe link 제거 |
| nopcie | BIOS에서 PCIe tunneling 금지. 일부 USB4 system에서 제공 |
현재 level은 `/sys/bus/thunderbolt/devices/domainX/security`에서 읽으며 `domainX`는 host controller가 관리하는 domain입니다. controller당 보통 domain 하나가 있습니다.
`user` 또는 `secure`이면 PCIe tunnel을 만들기 전에 사용자가 device를 authorize해야 합니다. 연결 device는 `/sys/bus/thunderbolt/devices` 아래에 나타나며 name과 UUID 등 identification 정보를 제공합니다.
Authorizing devices when security level is ``user`` or ``secure``
101-162device를 연결하면 다음과 같은 sysfs attribute가 나타납니다.
/sys/bus/thunderbolt/devices/0-1/authorized - 0
/sys/bus/thunderbolt/devices/0-1/device - 0x8004
/sys/bus/thunderbolt/devices/0-1/device_name - Thunderbolt to FireWire Adapter
/sys/bus/thunderbolt/devices/0-1/vendor - 0x1
/sys/bus/thunderbolt/devices/0-1/vendor_name - Apple, Inc.
/sys/bus/thunderbolt/devices/0-1/unique_id - e0376f00-0300-0100-ffff-ffffffffffff`authorized`가 `0`이면 아직 PCIe tunnel이 없습니다. 다음 명령으로 authorize합니다.
# echo 1 > /sys/bus/thunderbolt/devices/0-1/authorizedsecure connect를 지원하고 domain level이 `secure`이면 미래 connection의 authorization과 challenge에 쓸 random 32-byte 값을 담는 `key` attribute가 추가됩니다.
/sys/bus/thunderbolt/devices/0-3/authorized - 0
/sys/bus/thunderbolt/devices/0-3/device - 0x305
/sys/bus/thunderbolt/devices/0-3/device_name - AKiTiO Thunder3 PCIe Box
/sys/bus/thunderbolt/devices/0-3/key -
/sys/bus/thunderbolt/devices/0-3/vendor - 0x41
/sys/bus/thunderbolt/devices/0-3/vendor_name - inXtron
/sys/bus/thunderbolt/devices/0-3/unique_id - dc010000-0000-8508-a22d-32ca6421cb16key 기본값은 비어 있습니다. secure connect를 쓰지 않으려면 `authorized`에 `echo 1`을 실행해 `user` level과 같은 방식으로 tunnel을 만듭니다.
secure connect를 처음 설정할 때 key를 만들고 device에 보냅니다.
# key=$(openssl rand -hex 32)
# echo $key > /sys/bus/thunderbolt/devices/0-3/key
# echo 1 > /sys/bus/thunderbolt/devices/0-3/authorizedPCIe tunnel이 만들어지고 key는 device NVM에도 저장됩니다. 다음 연결에서는 같은 key로 device를 challenge합니다.
# echo $key > /sys/bus/thunderbolt/devices/0-3/key
# echo 2 > /sys/bus/thunderbolt/devices/0-3/authorizeddevice가 반환한 challenge가 key 기반 예상값과 같으면 연결하고, 실패하면 tunnel을 만들지 않고 error를 반환합니다. 그래도 연결하려면 key 없이 approve하거나 새 key를 쓴 뒤 `authorized`에 1을 써 NVM에 저장할 수 있습니다.
De-authorizing devices
163-178`authorized`에 `0`을 쓰면 de-authorize할 수 있습니다. connection manager 지원이 필요하며 domain `deauthorization` attribute가 `1`이면 지원됩니다.
de-authorize하면 parent PCIe downstream/root port에서 device upstream port까지 tunnel을 해제합니다. PCIe hot-remove와 같아 다시 authorize할 때까지 해당 topology에 접근할 수 없습니다. NVMe 같은 storage filesystem을 정상 종료하지 않았다면 data loss 위험이 있습니다.
DMA protection utilizing IOMMU
179-1982018년 이후 Thunderbolt port system은 IOMMU를 native 지원할 수 있습니다. driver가 device에 할당한 범위 밖 memory에 접근하지 못하게 하며 Linux는 사용자가 이미 켜지 않았다면 자동 활성화합니다.
`/sys/bus/thunderbolt/devices/domainX/iommu_dma_protection`에서 `1`을 읽으면 해당 system입니다. IOMMU가 DMA를 보호하므로 security level은 중복되어 일부 system은 `none`, older OS downgrade를 고려한 system은 `user`로 출하합니다.
IOMMU DMA protection이 있을 때 자동 authorize하려면 다음 `udev` rule을 사용합니다.
ACTION=="add", SUBSYSTEM=="thunderbolt", ATTRS{iommu_dma_protection}=="1", ATTR{authorized}=="0", ATTR{authorized}="1"Upgrading NVM on Thunderbolt device, host or retimer
199-258기능 대부분이 host controller나 device firmware에서 실행되므로 bug fix가 포함된 최신 firmware로 upgrade할 수 있어야 합니다. OEM support site 또는 Thunderbolt Updates site에서 얻을 수 있습니다.
device·host·retimer에 맞는 image인지 반드시 확인해야 하며 잘못 쓰면 special tool 없이는 제대로 사용할 수 없게 될 수 있습니다. Apple Mac host NVM upgrade는 지원하지 않습니다.
image를 받은 뒤 host controller가 나타나도록 Thunderbolt device를 연결합니다. device NVM을 갱신한다면 해당 device여야 하며, platform에 OEM-specific force power가 있으면 연결하지 않아도 됩니다.
Intel NUC6i7KYK(Skull Canyon) 예에서 non-active NVM에 firmware를 씁니다.
# dd if=KYK_TBT_FW_0018.bin of=/sys/bus/thunderbolt/devices/0-0/nvm_non_active0/nvmem완료되면 NVM authentication과 upgrade를 trigger합니다.
# echo 1 > /sys/bus/thunderbolt/devices/0-0/nvm_authenticateerror가 없으면 controller가 잠시 사라졌다가 driver가 감지해 full power cycle을 시작하고 다시 functional 상태로 나타납니다. 다음 명령으로 새 NVM이 active인지 확인합니다.
# cat /sys/bus/thunderbolt/devices/0-0/nvm_authenticate
0x0
# cat /sys/bus/thunderbolt/devices/0-0/nvm_version
18.0`nvm_authenticate`가 `0x0` 이외 값이면 마지막 authentication cycle의 error code로 image 인증 실패를 뜻합니다. NVMem device 이름 `nvm_activeN`과 `nvm_non_activeN`의 N은 NVMem subsystem 등록 순서로 붙는 identifier입니다.
Upgrading on-board retimer NVM when there is no cable connected
259-287platform이 지원하면 USB4 port에 아무것도 연결하지 않고 on-board retimer NVM을 갱신할 수 있습니다. `usb4_portX` device의 `offline`과 `rescan` attribute를 사용합니다.
먼저 USB4 port를 offline mode로 둡니다.
# echo 1 > /sys/bus/thunderbolt/devices/0-0/usb4_port1/offlinehotplug response를 막고 retimer power를 켠 뒤 scan합니다.
# echo 1 > /sys/bus/thunderbolt/devices/0-0/usb4_port1/rescanenumerate된 retimer NVM을 cable 연결 시와 같은 방식으로 갱신합니다. offline mode에서는 retimer가 disconnect되지 않으므로 `nvm_authenticate`에 1을 쓴 뒤 5초 이상 기다리고 다시 rescan합니다.
# echo 1 > /sys/bus/thunderbolt/devices/0-0/usb4_port1/rescan성공하면 port를 functional state로 돌립니다.
# echo 0 > /sys/bus/thunderbolt/devices/0-0/usb4_port1/offlineUpgrading NVM when host controller is in safe mode
288-298기존 NVM이 제대로 authenticate되지 않았거나 없으면 host controller는 새 image flashing만 가능한 safe mode로 들어갑니다. `nvm_version` read는 `ENODATA`로 실패하고 device identification 정보도 없습니다. 이전 절과 같은 방식으로 valid NVM image를 flash해 복구합니다.
Tunneling events
299-331`thunderbolt_domain`의 tunneling이 바뀌면 driver가 userspace에 `KOBJ_CHANGE` event를 보내며 다음 environment variable을 포함합니다.
TUNNEL_EVENT=<EVENT>
TUNNEL_DETAILS=0:12 <-> 1:20 (USB3)| `<EVENT>` | 의미 |
|---|---|
| activated | tunnel 생성·활성화 |
| changed | bandwidth allocation 등 tunnel 변경 |
| deactivated | tunnel 해제 |
| low bandwidth | optimal bandwidth를 받지 못함 |
| insufficient bandwidth | 현재 tunnel 요구를 만족할 bandwidth 부족 |
`TUNNEL_DETAILS`는 tunnel이 알려진 경우에만 제공합니다. Firmware Connection Manager에서는 없거나 불완전하고 Software Connection Manager에서는 full detail을 포함합니다. 현재 format은 driver log와 같지만 미래에 바뀔 수 있습니다.
Networking over Thunderbolt cable
332-355Thunderbolt cable로 연결한 두 host가 software communication을 할 수 있습니다. 임의 traffic tunnel이 가능하지만 현재는 Apple ThunderboltIP protocol만 지원합니다.
상대 host가 Windows나 macOS이면 cable만 연결하면 `thunderbolt-net` driver가 자동 load됩니다. 양쪽이 Linux면 한 host에서만 수동 load합니다.
# modprobe thunderbolt-net다른 host의 module load도 자동 trigger합니다. built-in driver면 추가 작업이 없습니다. port마다 `thunderbolt0` 같은 virtual ethernet interface를 만들며 `ifconfig` 같은 userspace tool이나 GUI로 설정할 수 있습니다.
Forcing power
356-364많은 OEM은 아무것도 연결하지 않아도 controller power를 On으로 강제하는 방법을 제공합니다. 지원 machine에서는 WMI bus의 `force_power` sysfs attribute로 노출되며 `Documentation/ABI/testing/sysfs-platform-intel-wmi-thunderbolt`를 참조하십시오. 현재 platform의 force-power state를 query할 수는 없습니다.
요약과 해설
thunderbolt.rst:1-364Thunderbolt의 PCIe tunnel은 connected device를 DMA master로 만들 수 있으므로 authorization과 IOMMU가 보안 경계입니다. 모든 device 자동 authorize rule은 편리하지만 DMA attack 방어를 우회합니다.
NVM upgrade는 잘못된 image로 device를 사용할 수 없게 만들 수 있으므로 OEM 적합성, non-active image 기록, authentication 결과, power-cycle 복구 절차를 반드시 확인해야 합니다.