This document discusses:
- Security risks associated with USB4 peripherals
- ChromeOS' approach to mitigating the risks
*** note USB4 specification includes interoperability with USB Type-C Alternate Mode and more significantly, Thunderbolt. This document also applies to Thunderbolt peripherals connected to a Chromebook USB4 host since they require very similar security considerations.
ChromeOS uses USB Guard and USB Bouncer to mitigate threats associated with legacy USB (USB3 and earlier). These mitigations are equally effective for legacy USB devices attached to a USB4 Chromebook host. We treat USB3 as the baseline and limit our discussion to incremental risks introduced by USB4.
PCI Express (PCIe) Tunneling is a prominent feature of USB4 (and Thunderbolt) peripherals. This feature provides an external peripheral with Direct Memory Access (DMA) to Chromebook's System Memory (DRAM).
Additionally, PCIe Tunneling entails external Peripherals interacting directly with corresponding device drivers running in the highly privileged kernel mode. In other words, PCIe device drivers now directly contribute to the kernel attack surface available to a malicious USB4 (or Thunderbolt) peripheral.
The security measures discussed below aim to mitigate a short-term, physically present attacker from using a malicious USB4 (or Thunderbolt) peripheral to steal user data directly from System Memory.
ChromeOS utilizes I/O Memory Management Units (IOMMUs) to control and limit System Memory locations that are directly accessible to external peripherals. By default, the peripheral can access nothing. Only the kernel or its device drivers are able to open up explicit System Memory locations for direct access by the peripheral.
Additionally, ChromeOS also configures the kernel to be stricter in regards to DMA access from external peripherals. These extra mitigations close certain spatial and temporal gaps that allow limited DMA access to unintended data. Specifically, ChromeOS employs the following Linux kernel options for external peripherals:
- Bounce buffers when requested allocation or mapping is smaller than IOMMU granularity
- Synchronous IOTLB flushing
One de-facto industry name for this technique is Kernel DMA Protection. Therefore it's worth mentioning that ChromeOS also provides DMA protection during early boot i.e during the firmware or Coreboot phase. This protection is implicit because PCIe Tunneling for external peripherals is disabled in the Coreboot environment.
ChromeOS currently allows a limited, vetted subset of device drivers to interact with external PCIe peripherals. This helps reduce the kernel attack surface exposed to a malicious device. In absence of this allowlist, a malicious device could easily convince the kernel to bind it to a particularly buggy device driver. Our vetting process includes fuzzing and auditing the device-facing interface of the driver.
Academic research (such as Thunderspy) has shown that trivial UUID based device authentication is inadequate to prevent spoofing. We also do not want to click fatigue ChromeOS users by asking them to authenticate devices. ChromeOS therefore does not rely on UUID based peripheral authentication.
*** note Despite the name, DMA protection and driver allowlist are always active even if Data access protection is disabled.
For maximum security against residual risk, PCIe Tunnels are forbidden by default. ChromeOS requires the Chromebook owner or an equivalent Enterprise IT admin to explicitly enable them by opting out of Data access protection for peripherals. More information on this can be found in the help article on Connecting your Chromebook to Thunderbolt & USB4 accessories
ChromeOS prohibits authorization of new PCIe tunnels on login or lock screens. ChromeOS also prohibits PCIe tunnels in a Guest session. Existing PCIe tunnels are deauthorized on user logout. For sake of user experience, already authorized PCIe tunnels remain authorized if a user locks their session without logging out completely.
Putting the above rules together, ChromeOS will automatically authorize any PCIe tunnel if:
- Data access protection for peripherals is disabled for the Chromebook and
- A non-guest user session is active and unlocked
ChromeOS will automatically deauthorize PCIe tunnels if:
- The user signs out or
- The peripheral is disconnected or
- Data access protection for peripherals is enabled
ChromeOS falls back to safer legacy alternate modes whenever all of the following conditions are met:
- PCIe tunneling is prohibited by policy
- The peripheral does not support USB4
- The peripheral supports such a legacy alternate mode.
One such fallback mode is a USB Type-C Alternate mode which is supported by some newer Thunderbolt 3 peripherals -- DisplayPort Alternate mode. This mode carries DP and also USB sans PCIe tunnels. Some user experience examples that this helps without sacrificing on security:
- Allow the user to login or unlock their docked Chromebook via a display and keyboard attached to the dock.
- Provide limited dock functionality without requiring the Data access protection opt-out.
USB4 devices are managed by two ChromeOS daemons. Their main responsibilities in this context are as follows:
- Source of truth for the device driver allowlist
- Performs PCIe tunnel authorization and deauthorization based on user session state
- Manages Type-C modes. Enters USB4, Thunderbolt alt mode, Type-C alt mode, etc based on Data access protection for peripherals and user session states.