Thunderbolt talk from LCA2018

From: Joel Wirāmu Pauling <joel@aenertia.net>
Subject: [Thunderbolt-Software] Lca2018 talk
Date: Thu, 25 Jan 2018 15:51:10 +1300
To: thunderbolt-software@lists.01.org

Hi all; I delivered my talk on tb3 (and some other things this morning) at Linuxconf Australasia. I’ve made all my benchmarking tests using flent available (and some dmesg
dumps of crash situations etc) public. Hopefully this of help to someone, and Wellcome feedback.




Thunderbolt-software-user-space in Ubuntu

Colin Ian King of Canonical has been packaging up the Intel Thunderbolt user-space software for Ubuntu. His Tweets are private, but he just tweeted that the tool is now in Ubuntu!


Thunderbolt user-space components:

[…]The user-space components implement device approval support:
* Easier interaction with the kernel module for approving connected devices.
* ACL for auto-approving devices white-listed by the user.

So far, I’ve not found a public security page for Thunderbolt. Only a “Fun Facts” page… 😦 I was hoping to find a page listing Thunderstrike, Thunderstrike2, the Legbacore t2e tool, CIA Sonic Screwdriver, PCILeech, etc.



Dmytro on Apple PCI-E Thunderbolt


Linux 4.10 UEFI changes

Matt Fleming posted UEFI changes for Linux 4.10 kernel.

Folks, please pull the following v4.10 material. There isn’t a huge amount of stuff here. The biggest change is the EFI dev path parser code from Lukas to get thunderbolt working on his macbook.
 * Fix an allocation bug in the generic EFI libstub where alignment and adjusted size isn’t taken into account – Roy Franz
 * Update the EFI MAINTAINERS entry to include ARM and arm64 files and directories – Ard Biesheuvel
 * Add new feature to seed the RNG from the stashed value returned by EFI_RNG_PROTOCOL in EFI stub and wire up for ARM/arm64 – Ard Biesheuvel
 * Retrieve Apple device properties from within the EFI stub to fully support thunderbolt devices on Apple Macbooks – Lukas Wunner

More details on the Thunderbolt patch:

thunderbolt: Use Device ROM retrieved from EFI:
Macs with Thunderbolt 1 do not have a unit-specific DROM: The DROM is empty with uid 0x1000000000000. (Apple started factory-burning a unit- specific DROM with Thunderbolt 2.) Instead, the NHI EFI driver supplies a DROM in a device property. Use it if available. It’s only available when booting with the efistub.  If it’s not available, silently fall back to our hardcoded DROM.  The size of the DROM is always 256 bytes. The number is hardcoded into the NHI EFI driver. This commit can deal with an arbitrary size however, just in case they ever change that.  Background information: The EFI firmware volume contains ROM files for the NHI, GMUX and several other chips as well as key material. This strategy allows Apple to deploy ROM or key updates by simply publishing an EFI firmware update on their website. Drivers do not access those files directly but rather through a file server via EFI protocol AC5E4829-A8FD-440B-AF33-9FFE013B12D8. Files are identified by GUID, the NHI DROM has 339370BD-CFC6-4454-8EF7-704653120818.  The NHI EFI driver amends that file with a unit-specific uid. The uid has 64 bit but its entropy is much lower: 24 bit represent the model, 24 bit are taken from a serial number, 16 bit are fixed. The NHI EFI driver obtains the serial number via the DataHub protocol, copies it into the DROM, calculates the CRC and submits the result as a device property.  A modification is needed in the resume code where we currently read the uid of all switches in the hierarchy to detect plug events that occurred during sleep. On Thunderbolt 1 root switches this will now lead to a mismatch between the uid of the empty DROM and the EFI DROM. Exempt the root switch from this check: It’s built in, so the uid should never change. However we continue to *read* the uid of the root switch, this seems like a good way to test its reachability after resume.

git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git tags/efi-next


more info on PCI Leech

 DMA attacking over USB-C and Thunderbolt 3
I just got an Intel NUC Skull Canyon that has an USB-C port capable of Thunderbolt 3. Thunderbolt is interesting since it’s able to carry PCI Express which is Direct Memory Access (DMA) capable. I have previously demonstrated how it is possible to DMA-attack macs over Thunderbolt 2 in my DEF CON talk “Direct Memory Attack the Kernel”. To attack my MacBook Air in the DEF CON demo I used a Sonnet Echo ExpressCard Thunderbolt 2 to ExpressCard adapter together with a PCILeech ExpressCard. I also got a Thunderbolt 3 to Thunderbolt 2 adapter from Startech and I wanted to try it on the NUC to see if it’s possible to use it for DMA attacks, or if Thunderbolt has been secured. […]




additional Apple device property support for Linux efistub

Lukas Wunner submitted a 6-part patch to the Linux-(EFI,Kernel) lists with additional Apple EFI firmware support.

Apple device properties
Apple EFI drivers supply device properties which are needed to support Macs optimally. This series extends the efistub to retrieve the device properties before ExitBootServices is called (patch [1/6]). They are assigned to devices in an fs_initcall (patch [5/6]). As a first use case, the Thunderbolt driver is amended to take advantage of the Device ROM supplied by EFI (patch [6/6]). A by-product is a parser for EFI Device Paths which finds the struct device corresponding to a given path. This is needed to assign properties to their devices (patch [3/6]). […]

For more info: