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:


Intel 01.org mailing lists

It is sometimes funny to watch a company do open source. Intel’s 01.org, for Open Source projects, has a mailing list server with multiple lists:

There are lists for LUV and CHIPSEC. These work fine!

There is a list for Thunderbolt Software. …but it is a closed list, with no public archives. 😦

The text that it is a closed list:
“This is a hidden list, which means that the list of members is available only to the list administrator.”

There’s a list for Intel Kernel Guard Technology (KGT). It also is a closed list, with the same text as the Thunderbolt list. BUT, their archives are publicly-available.

There’s a list for BIOS Implementation Test Suite (BITS)!
But there are no archives, perhaps a closed list, or just broken archives?

I rather wish Intel used intel.com or 01.com for closed lists, and kept the Open Source-centric 01.0rg’s list all public, with working archives. 😦


Intel 01.org Thunderbolt project

I just noticed a Thunderbolt software project on 01.org, the Intel Open Source project site:


The last release was a few months ago. However, this is not a normal open source project. It is “restricted open source”, only only for Thunderbolt vendors, not the public.

The code can be accessed from the restricted Git Hub at: https://github.com/01org/thunderbolt-software
An access can requested at thunderbolt-linux@intel.com only for manufacturers having a valid Thunderbolt technology license.