This is it I think. The T2 is now acting as a killswitch against any hardware intrusion on the mbp, no reason not to expect it to be such on the next macpro. Even if it does come with an internal pcie slot, unless you are rocking some particular Apple software tool, opening the box to insert a GPU will more than likely temporarily brick the box until a genius can run the software to unlock it again.
This is primarily just hysteria more than fact. The "intrusion detection" isn't the core issue. Security subsystem tamper resistant is far more like the driver here. ( e.g., Servers being tampered with before deployment stories.
https://www.macrumors.com/2018/10/07/apple-to-congress-nothing-found-chip-hack/
Google's Titan (for servers ) chip outlined at this year's Hot Chips 2018
https://www.anandtech.com/show/13248/hot-chips-2018-google-titan-live-blog-6pm-pt-1am-utc )
A pluggable GPU is a rather poor vector for a disrupting the core "root of trust" of the system as opposed to the other aspects directly under the T2 control: boot firmware, low level power management , default boot OS image , user authentication ( fingerprint reader and/or video/audio (face/voice ) ).
The content the GPU handles is displayed on the screen anyway. It is an output
to the user ; not
from the user. So it is unlikely there is any user metrics to clandestine capture and anybody looking at the screen can see the output. As long as the boot drivers for the GPU are signed and authenticated, it is a highly benign subsystem device from a security standpoint.
The T2 kill switch is supposedly kicks in (
https://www.macrumors.com/2018/10/06/ifixit-repairs-2018-mbp-without-apple-diagnostics/ ) if replace the NAND daughtercards of the SSD (iMac Pro ) or cameras/logic board (hence T2 itself ) / TouchID (fingerprint ) systems.
Likewise, a "data' (non boot ) drive outside the boot process isn't all that high of a security "root of trust" problem. [ At least when not being used as a boot drive. ] . Bluetooth/Wifi is on a slippery slope. I imagine there are some ultra secure folks would would prefer if those could be unplugged from the system ( so not a reset trigger. )
Could Apple make it an optional setting. It is already in the "optional" mode now (given iFixit made replacements ). "Planned obsolesce" isn't the primary driver here really ( it has some side effect issues ) but whether this is a manufactured secure device is a problem that requires solutions.
[doublepost=1539020045][/doublepost]
....
T2's disk controller is a possibly sticking point with changing internal drives though. We'll see where Apple lands on that. I honestly think enforcing encryption on the built in drives on a desktop is a little silly.
Long ago SanForce SSD controllers encrypted everything by default. The data was always managed at rest compressed and encrypted. That has helpful attributes when dealing with error corrections and encodings on 'raw' NAND flash cells which can loose bits. For example several sectors of '1111' in a row means have lots of electrons to trap in a narrow area. Encrypted it can't be that uniform. ( encryptions raise the 'entropy' (randomness) of the data while compression can move the opposite way. ).
If the data is going to be encrypted anyway then can put a formal password on it. (for controllers like SanForce the nominal mode was to have a key that was built into the drive by default and just decrypt with no password 'covering' the the key. )
Apple's stance of "FileValut" being completely detached from the disk level had problems if trying to solve the issues with your own home grown SSD controller. Some of this is the mix of Apple and them being in the SSD business but only for their own devices. So their SSDs only work for their devices.
That is OK. That only becomes a substantive problem when their SSDs are the only options. ( same for GPUs implementations being the only option.). If allowed some 3rd party SSDs some of them will be encrypt/decrypting too.
[doublepost=1539020958][/doublepost]
Apple's comments on GPU throughput make me think otherwise. While eGPU/Thunderbolt throughput is good enough for most, that wouldn't match up with Apple's comments on wanting to support the most demanding GPU workflows. So I don't really see eGPU/Thunderbolt being where Apple goes as a GPU bus link.
For greater than two GPUs eGPU would likely be the default option. The MBP 15" has two GPUs but if want more than two in your set-up then it is eGPU. Mac Pro, even with less physical volume constraints, probably will fall into the same boat.
The primarily GPU being outside the box makes no sense. It leaves the Mac with a basically incomplete system (minus act of attaching a monitor or running headless ).
A second GPU ( a compute , accelerator , etc. ) would not be a huge issue if go back to desk-side like volume constraints.
I'd give decent odds that them playing with all these third party GPUs for Mojave on the Mac Pro 5,1 is them possibly piloting off the shelf GPU support for the next Mac Pro.
Most of the GPUs on Apple's "many of these will work" list are GPUs that are part of Apple custom designs. I don't think that is an off the shelf indicator. The rest of the Mac line up also has several discrete GPUs and most of those will probably continue to "happen to work" as secondary GPU cards in eGPU or in an empty slot of a new Mac Pro. The bulk of the GPU driver work has to be done anyway.
Apple's custom embedded cards could be a derivative of the baseline reference designs. What the Mac Pro would need is "boot" and clean integration with the Thunderbolt subsystem for the primary card.
Might be why Apple's bug response have shown interest in cards like Vega that shouldn't even be recommended on a Mac Pro 5,1 for power reasons. Mac Pro 5,1 users could be beta testing changes for the next Mac Pro already.
Apple ships systems with Vega in them now (iMac Pro) . They should be interested in non boot phase issues popping up with Vega anyway.
(Not beta testing actual firmware obviously. More like testing drivers against PCIe cards.)
It would be helpful for Apple compartmentalizing the non boot driver development for the Mac ecosystem.
A new Mac Pro at AMD or Nvidia could spend time bootstrapping their own reference card without revealing more of new Mac system than necessary.