
Thunderbolt 3 Unblocker - okket
https://github.com/rgov/Thunderbolt3Unblocker
======
Filligree
From the TB3 enabler GitHub:

"For unknown reasons, Apple decided to block the support for some categories
of Thunderbolt 3 peripherals under macOS and when you connect those
Thunderbolt 3 peripheral, you simply get an "Unsupported" message under
Thunderbolt Device Tree. After digging around, it turns out the block is
implemented in software level and it is possible to bypass the block by
patching the related kext. This patch modifies IOThunderboltFamily and allows
"Unsupported" Thunderbolt 3 peripherals to work under macOS Sierra."

I wonder why they did that. Stability, probably?

~~~
txcwpalpha
Security issues, most likely. Like Firewire, Thunderbolt suffers from the same
security issue in that to achieve its high speeds, it gives connected devices
direct memory access. In other words, any connected device can read and write
directly from your RAM, bypassing any kind of access control built into the
OS.

[https://en.wikipedia.org/wiki/Thunderbolt_(interface)#Vulner...](https://en.wikipedia.org/wiki/Thunderbolt_\(interface\)#Vulnerability_to_DMA_attacks)

~~~
userbinator
Thunderbolt is basically external PCIe, so that's not surprising.

Quite frankly, I'm not worried about physical access being a "vulnerability"
\--- I'm of the "if you physically own it, you should logically own it"
mindset.

~~~
lawl
While I mostly agree with this, I don't agree here. Maybe you need to connect
your notebook to a projector and they hand you a thunderbolt to hdmi cable.

They don't phsically own your device and yet you're possibly fucked.

~~~
Klathmon
Couldn't a simple OS "permissions" system mostly fix that loophole (as much as
it can be fixed)?

"[device name] is requesting [scary sounding permission] Allow?"

It won't protect users from themselves, but it will protect "bad-usb" style
attacks.

~~~
kbenson
No, because when you have full access to RAM, there's no actual distinction in
those messages for thunderbolt devices.

Unless maybe you meant just the same scary message for every thunderbolt
device, in which case people become acclimated to ignoring the message. And
that may be after they've wasted support time asking why some device wants
this scary access.

~~~
andreiw
IOMMU? You still get to lock down access per device...or the Mac laptops don’t
have an IOMMU?

~~~
darpa_escapee
Many laptops ship with a disabled IOMMU or without one.

------
dmitrygr
The code for xnu_override (the library the author wrote to patch functions in
the kernel) is wrong for a number of serious reasons.

It assumes (with no verification) that the first twelve bytes of any kernel
function you could want to patch are all one basic block and do not contain a
jump target or a relative branch. These reasons _ARE_ why live patching is
hard and why proper support for it is basically required in original code
(making sure each func starts with a basic block at least twelve bytes long).
Without that, it's quite a dangerous game to play in kernel space.

Furthermore, it assumes RAX is safe to clobber. This may not be so. Compilers
are generally free to ignore standard ABI when calling provably-static
provably-leaf functions. Who said RAX doesn't have a useful value on entry to
patched function?

Additionally, it edits cr0 and cr3 with interrupts enabled, allowing it to be
preempted during this action. If said preemption happens, another edit to
those registers could happen in between. Scary, since what's being done is a
non-atomic read-modify-write on CPU control registers.

Strongly advise anyone from running this on any system.

~~~
munin
> Strongly advise anyone from running this on any system.

Oh come on. Your para 2-4 are serious conceptual defects with xnu_override in
general, but this is the kind of hacker shit you'd expect to find in something
that will live patch your kernel code. At the point in time you find yourself
turning off SIP to load some code to hot patch your kernel, you've long since
crossed the Rubicon of caring about running particularly good code.

The odds are good that the functions this thing is set up patch do hold with
your first two invariants (RAX is scratch, there's 12 bytes in the entry BB).
The third is the race, and you'll probably win this race most of the time.

"You'll probably win this race most of the time" shouldn't be in any serious
engineering design document and is probably grounds for demotion or firing if
you bring it up as a defense during a design or code review, but that isn't
what's going on here. This is some hacker shit posted to github.

~~~
dmitrygr
And if this project was one monolithic thing, I'd agree. But the page sells
this _xnu_override_ as a "reusable library" which might lead someone to try to
reuse it in another place. This is scary and hence my warning. Hell,
tomorrow's apple 10.13.0.0.0.0.0.0.minor.insignificant.0.1 patch could change
these "invariants"

~~~
munin
You're right, and I was reacting poorly to the "don't run this on anything"
statement. It's some hacker magic off github, caveat empor. You're also right
that future updates could break it. It's brittle. I won't be running it
myself.

I bet, though, that 99% of the time, it works every time, and for its use
case, that's "good enough." Hot patching the kernel is scary, though, and
hopefully no one walks away from looking at that github thinking "oh yes, I
know so many problems that can be solved by hot patching the running kernel"
because honestly getting the act of patching the physical code itself is only
the start of your troubles.

------
DRW_
FYI, this block was found back at the launch of the first Thunderbolt 3 Macs
to be because Apple (for whatever reason) didn't wish to support the older
Thunderbolt 3 chipset, according to peripheral manufacturer, Plugable:

 _The version of OS X on the new MacBook Pros (late 2016) will not work with
existing Thunderbolt 3 docks and adapters that were certified for Windows
prior to the release of the MacBook Pro. These existing devices use first
generation of TI USB-C chipset (TPS65982) in combination with Intel’s
Thunderbolt 3 chipset (Alpine Ridge). Apple requires the 2nd generation
TPS65983 chipset for peripherals to be compatible. Certification of solutions
across different device types is still in-progress for this 2nd generation
chipset. From the Plugable product line, our dual display graphics adapters
for DisplayPort and HDMI (TBT3-DP2X and TBT3-HDMI2X) are affected… We’ve also
postponed our TBT3-UD1 Docking Station to update to the TPS65983 chipset and
re-certify to make this docking station MacBook-compatible. Our Flagship
TBT3-UDV dock with Power Delivery /Charging was already planned to use the
next generation controller chip from TI, and will be compatible with the 2016
Thunderbolt 3 MacBooks._

I still don't think we exactly know why, but the allegations that they're
doing it for profit or for some attempt to control the ecosystem don't seem to
hold up, especially since most of these peripheral manufacturers since updated
their devices with the new chipset to work with macOS just fine.

------
sschueller
Why would anyone (specifically developers) buy another apple product if they
now start blocking hardware from working on PCs?

Them blocking battery extenders with headphone jacks on the iPhone is already
bad enough, but doing it to PCs is a whole other level of walled garden.

~~~
orf
What if the hardware _doesn 't_ work on the PC though? Isn't that the point?

~~~
Piskvorrr
FWIW, the current case seems to be "hardware works just as the spec says, OS
blocks in anyway."

Mind you, I've seen many types of HW, some of which indeed wouldn't work "with
a PC." The expected course of action was always "complain at peripheral
vendor," this "we know what you want, but nope because FU that's why" has
historically been reserved for vendors trying to keep out competition.

So, while it is theoretically possible that an OS-enforced soft block is there
to protect the user, a statistically more probable version is that it exists
to protect the OS maker from competition; IMNSHO the ball is in Apple's court
to prove otherwise.

~~~
userbinator
_FWIW, the current case seems to be "hardware works just as the spec says, OS
blocks in anyway."_

I've noticed a disappointing and somewhat repulsive trend increasing over the
past few years, one which not only Apple participates in (but they are one of
the most notable), of moving from "not supported" meaning "we won't help you
with it" (fair enough) to "we will actively stop you from doing it" (FU for
even trying to do something we didn't think of/don't want/etc.).

IMHO it's perfectly reasonable for a company to not offer support for
literally every hardware combination out there, because that's a huge space;
but to deliberately sabotage attempts at doing things outside of that boundary
is incredibly hostile. I have no definitive evidence but this trend seems at
least somewhat correlated with the rise of authoritarianism.

As a developer myself, and also someone who has done many "unsupported" things
with no ill effect, I constantly try to fight this position from others, but
it's difficult.

------
wslh
That is great, I found Thunderbolt the best solution for using notebooks at
home and work (multiple monitors, USB ports). I only hope in the future you
can connect external GPUs in some way. I have tried via PCIe with an external
board but it is not the best solution (performance, unsupported), it is just a
hack.

~~~
n1000
I've been using eGPUs for gaming (on Windows though) on my MacBook Pro for a
few years now. macOS introduced official eGPU support and now there seem to be
numerous compatible enclosures: [https://egpu.io/macos-high-sierra-official-
external-gpu/](https://egpu.io/macos-high-sierra-official-external-gpu/)

~~~
xirdstl
Which GPU are you using?

~~~
n1000
nvidia gtx 970. My setup is pretty diy with an external 200W power supply.
Today I would get one of those nice enclosures mentioned in the article. You
loose around 10% performance compared to an internal GPU.

BTW: Windows 10 also has pretty solid eGPU support on my MBP at least.

