13th gen Intel: Thunderbolt controller in thunderbolt control center

The 13th gen Intel webpage list the ports as thunderbolt 4 AND USB-4.

I don’t see any thunderbolt controller in my Windows 11 device manager.
Using the “Thunderbolt control center” app, I don’t see any controller or any devices when connected via usb-c port.

BUT, my egpu is recognize correctly and I can see it in GPU-Z and use it.

So… is my system configured as a USB-4 system or a am I missing something.

I have no unrecognized devices in the device manager app. I installed the driver pack.

I also have an HP spectre with a 11th gen Intel and I have a thunderbolt controller in device manager AND I see it in the Thunderbolt control center app.

I don’t think the thunderbolt controller is different between 11th gen and 13th gen because it’s built-in the CPU.

I am asking this question because my understanding is that, when you are Thunderbolt 4 certified, you get the driver and the device in device manager.

If you are 99% compatible, you are not certified and you get USB-4 generic driver.

11th & 12th gen frame.work laptop were not certified (I think) but 13th gen IS, so why don’t we get the full setup ?

It is if you run the beta BIOS…which I am and Thunderbolt still doesn’t work right for me. I blame Intel.

Any update on this @Framework? Not having the ability to approve devices in control centre causes windows hello and Bitlocker to trip when thunderbolt decides are (un)plugged. I noticed there’s a 03.04 bios some users have on 13th gen Intel Framework 13s but it’s not on the downloads page yet - would the new bios fix it? (I’m on 03.03 bios)

This is completely unrelated. Windows11 mandates its own USB4 driver be used.
The Thunderbolt Control Center is superfluous when the USB4 driver works.
With Thunderbolt Control Center, firmware manages a lot of the connection and the OS has no insight, not even into the connected speed, while the USB4 drivers have the OS manage it, which provides so much more insight and control over the connection and makes firmware updates less relevant.

Approving devices has long been a thing of the past, even with legacy Thunderbolt drivers (since before TB4). There is nothing to approve, no settings to change, TB Control Center is useless when Windows’ USB4 drivers are working. This is been the case with the newest TB3 hosts and all TB4 hosts.

And whether your device is TB certified or not does not change that addtional BootROMs being bootet, external or internal are observable and trip Bitlocker in its default configuration.

FW could provide a new BIOS option as a feature upgrade that would allow to exclude external BootROMs (simply not boot them), as most users have no need for them anyway, but so far have not done that, so I would not count on them doing this ever for an existing device, even if they’d add this option to newly launched devices.

With a Dell on Win11 the thunderbolt control center works, and Bitlocker/Windows Hello don’t trip with the same thunderbolt devices. No bios or OS config changes were needed to make this work.

Does this mean the USB4 driver isn’t working properly then?

Does that laptop use the new USB4 driver? Then it will show the USB4 menu under Devices > USB that replaces TB Control Center with a far more detailed output.



(That Anker USB4 device is actually not even recognized at all by TB Control Center, even though it works, on certified TB4 devices, because it is a pure USB4 device without any TB support. So nobody should even want that crappy old and useless piece of software)

Microsoft mandates the USB4 driver be used for devices supporting it (CPU-integrated USB4 controller) and launching with Win11.
Most devices that launched with Win10 seem to still use the old way of doing it. And depending on the manufacturer the device may not include proper firmware to switch to the USB4 driver once upgraded to Win11. A Dell Inspiron device with Tiger Lake CPU I have access to is doing exactly this. Although Tiger Lake clearly also supported the new USB4 drivers, as at least Framework was using it.
I have not yet found a device that uses the USB4 drivers where you can still use the TB Control Center, but I do not know it that is impossible.

The TB Control Center has nothing to do with whether TB devices can trip Bitlocker or not.
TB4 already mandates that the old security levels no longer apply. TB4 hosts must support IOMMU-based security, that works from boot, hence TB connections are supposed to be established at boot-time already and no longer require you to manually approve them from TB Control Center as a hacky workaround to prevent various attacks from TB devices.

What trips Bitlocker on default settings, is that some PCIe devices have BootROMs (like GPUs in order to add drivers to the BIOS for video output during the early boot process, before the OS takes over with its own drivers). Bitlocker by default configures the TPM to measure all code that executes and ties the Bitlocker encryption key etc. to the exact measurement it was setup with.
Adding or removing any PCIe device with a BootROM, like a network card with PXE support will trip this, as it changes what code executes before Windows takes over.

Dell devices, like my own Dell XPS have a BIOS option, that by default prevents the BIOS from executing any BootROMs behind TB. While this option is off, you cannot use a eGPU during boot, PXE boot from a network card behind TB etc. As the OS has its own drivers and notebooks have their own screen to use until then, this impacts barely anyone and is a smart BIOS option to have, that I wish FW would also add.

Booting any BootROM that is signed for SecureBoot can also be a security issue, since some Linux distributions are also signed for that and can probably be abused to bypass those restrictions.

Bitlocker itself can only be configured to ignore the executed code measurement entirely, in which case the TPM would basically tell any OS from any external media you boot your secret disk encryption key. Windows or any driver has no control over what the BIOS has the TPM measure as part of “executed code”.

I guess that clears up some of my confusion of why I didn’t have to authorize my egpu when I tried it yesterday. Not having to have the whole authorization definitely goes a long way towards user-friendliness. As long as iommu prevents dma attacks all is well.

Isolation from other PCIe devices should be pretty much perfect.
But I have read some things about Linux, how it tries to not waste any space and may pack kernel & driver data closer to one another, than the IOMMU allows to isolate.
So it may leak read and or write access to some memory structures directly next to the ones, a driver wants to expose to a PCIe device.
I have not followed developments here close enough to know if this is a solved problem by now and which drivers might be effected. And I could not find information on whether Windows has this solved.

If anybody knows of a diagnostic way of dumping current IOMMU configuration and device-exposed data structures, that might be fun to take a look at.

Ahh this explains a lot. It seems like a frustratingly simple omission that would definitely make things work a lot better. It’s also annoying you can’t “teach” windows that you have two hardware setups and that both should be trusted.

Sadly it also breaks Windows Hello which has no option like Bitlocker that I could find.

Basically limitation of the TPM that would need to be worked around. And that is basically only relevant in combination with external PCIe-based connections of GPUs, so that not enough people care.

I’m guessing thunderbolt docks without GPUs are fine because it’s using DP alt mode over the thunderbolt cables instead yeah?

They are fine, but not because of that. Most TB controllers will still make a PCIe connection. For TB3, just for the USB features. For TB4 for TB-outputs.
if the dock contains a PCIe network adapter that supports PXE booting, that will also have a BootROM precisely for that boot support.
NVMe SSDs however are fine, because they are standardized and designed to be booted from without a BootROM (thats why you cannot boot them on a BIOS that does not support NVMe). (except for those very early Samsung NVMe that still included a BootROM precisely to work on pre-NVMe BIOSes)

I think that’s due to the 13th gen. I used the same system on the 8th i7(TB3) and the 13th i5(TB4). The thunder control panel shows nothing on the 13th i5. Also, the USB4 options show in the Windows control panel.

I’ve used to “approve” device in the thunder control panel, I’m not sure if I can still do this on 13th i5.

Modern TB4 / USB4 controllers need to support the technologies and features per spec that allow the OS to manage that, so there is no more approving at the controller itself. That was basically a stop gap solution , because the chipset and OS could not secure the rest of the system from potential malicious TB/PCIe devices.