linux-kernel - Re: Apple Thunderbolt Display chaining

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <YvI9Cbin4OKQwZ05@lahna>
Date:   Tue, 9 Aug 2022 13:55:05 +0300
From:   Mika Westerberg <mika.westerberg@...ux.intel.com>
To:     Brad Campbell <lists2009@...rfbargle.com>
Cc:     linux-kernel@...r.kernel.org
Subject: Re: Apple Thunderbolt Display chaining

Hi,

On Tue, Aug 09, 2022 at 06:40:54PM +0800, Brad Campbell wrote:
> G'day Mika,
> 
> 
> On 9/8/22 18:23, Mika Westerberg wrote:
> > Hi,
> > 
> > On Mon, Aug 08, 2022 at 09:27:24PM +0800, Brad Campbell wrote:
> >> If I don't authorize the PCIe tunnels and just leave the DP enabled it
> >> works fine also.
> > 
> > But you say that it fails on boot when the driver discovers the tunnels,
> > right? So there is really nothing to authorize (they should be already
> > "authorized" by the boot firmware).
> > 
> > If I understand correctly this is how it reproduces (the simplest):
> > 
> >   1. Connect a single Apple TB1 display to the system
> >   2. Boot it up
> >   3. Wait a while and it hangs
> > 
> > If this is the case, then the driver certainly is not creating any
> > PCIe tunnels itself unless there is a bug somewhere.
> > 
> > An additional question, does it reproduce with either TB1 display
> > connected or just with specific TB1 display?
> > 
> 
> No, I've not been clear enough, I'm sorry. I've re-read what I've written below and
> I'm still not sure I'm clear enough.
> 
> The firmware never sets anything up. 
> 
> When I cold boot the machine (from power on), the thunderbolt displays and tunnels
> remain dark until linux initializes the thunderbolt driver the first time. 
>  
> If I compile the thunderbolt driver into the kernel, or let the initramfs load it
> the displays come up, all PCIe tunnels are established and everything works.
> 
> When I reboot the machine (reset button or warm boot), the firmware continues to
> do nothing and all the tunnels remain in place. The machine dies when the thunderbolt 
> driver is loaded for a second time.
> 
> That might be a reset/warm boot with it compiled in or loaded from iniramfs.
> It may also be me loading it from the command line after booting with it as a
> module and blacklisted.
> 
> The problem comes about when the thunderbolt module is loaded while the PCIe tunnels
> are already established.
> 
> To reproduce in the easiest manner I compile the thunderbolt driver as a module and
> blacklist it. This prevents it from auto-loading.
> 
> I cold boot the machine, let it boot completely then modprobe thunderbolt and authorize
> the tunnels. I then warm boot which lets the kernel detect and init the DP displays
> and detect/configure all the PCIe devices. The thunderbolt driver is not loaded.
> 
> The machine comes up, all tunnels are established and all devices work.
> 
> If I then modprobe the thunderbolt driver, things break.
> 
> This is the hack in my boot script :
> 
> # Spark up thunderbolt
> if [ -z "`grep notb /proc/cmdline`" -a -z "`lsusb | grep '05ac:9227'`" ] ; then
> 	modprobe thunderbolt
> 	sleep 1
> 	echo 1 > /sys/bus/thunderbolt/devices/0-3/authorized
> 	echo 1 > /sys/bus/thunderbolt/devices/0-303/authorized
> 	reboot
> fi

Thanks for the clarification! How about on macOS side, does it work (I
would expect yes)?