Jump to content
  • Announcements

    • Allan

      Forum Rules   04/13/2018

      Hello folks! As some things are being fixed, we'll keep you updated. Per hour the Forum Rules don't have a dedicated "Tab", so here is the place that we have our Rules back. New Users Lounge > [READ] - InsanelyMac Forum Rules - The InsanelyMac Staff Team. 
dpgowan

T2 Chip, bad news for Hackintosh?

25 posts in this topic

Recommended Posts

https://www.macworld.com/article/3245764/macs/the-t2-chip-makes-the-imac-pro-the-start-of-a-mac-revolution.html

 

Been reading up on the new T2 chip and how it manages crucial processes such as the system boot, encryption, and Internal storage management. What dose this say for the future of Hackintosh?

 

We need to get raspberry Pi's to interface with our Hackintoshes, lol.   I was reading that same article a couple of days ago, we should be good for a few more years until Apple stops supporting older Macs without this chip.

Share this post


Link to post
Share on other sites

Apple supports Hackintosh and will not make something dangerous for us.


 

 

The T2 is responsible for controlling the iMac Pro’s stereo speakers, internal microphones, and dual cooling fans, all by itself.

Share this post


Link to post
Share on other sites

Apple supports Hackintosh and will not make something dangerous for us.

 

Could you explain more about this?  :o

Share this post


Link to post
Share on other sites

Apple supports Hackintosh and will not make something dangerous for us.

My worry is the bit about boot encryption to confirm the authenticity of the machine...sounds a lot like proprietary locks meant to keep people from building a Hackintosh or modify the machine.

 

https://www.google.com/amp/appleinsider.com/articles/17/12/12/imac-pro-debuts-custom-apple-t2-chip-to-handle-secure-boot-password-encryption-more/amp/

 

Also I wouldn’t say Apple “supports Hackintosh” as the very concept violates Apples terms for its Operating System. They disable the use of third party kexts by default, we bypass this in order to make a Hackintosh work.

 

 

Sent from my iPhone using Tapatalk

Share this post


Link to post
Share on other sites

My worry is the bit about boot encryption to confirm the authenticity of the machine...sounds a lot like proprietary locks meant to keep people from building a Hackintosh or modify the machine.

 

https://www.google.com/amp/appleinsider.com/articles/17/12/12/imac-pro-debuts-custom-apple-t2-chip-to-handle-secure-boot-password-encryption-more/amp/

 

Also I wouldn’t say Apple “supports Hackintosh” as the very concept violates Apples terms for its Operating System. They disable the use of third party kexts by default, we bypass this in order to make a Hackintosh work.

 

 

Sent from my iPhone using Tapatalk

Boot encryption is FileVault which we already have.

They disable the use of third party kext and allow us to disable SIP.

And this kext is also third party

138    0 0xffffff7f83319000 0x4000     0x4000     com.intel.driver.EnergyDriver (2.0) 7FE9AF4A-A8C2-3099-A956-971DDC86A467

is it disabled too?

It came with Intel Power Gadget 

As well there are kexts for scanners, WiFi, printers etc.

Share this post


Link to post
Share on other sites

Please notice that the T2 chip actually can be disabled.

I wonder how this will fair for performance though, and the possibility of it becoming a required component in the future for specific features.

 

Boot encryption is FileVault which we already have.

They disable the use of third party kext and allow us to disable SIP.

And this kext is also third party

138 0 0xffffff7f83319000 0x4000 0x4000 com.intel.driver.EnergyDriver (2.0) 7FE9AF4A-A8C2-3099-A956-971DDC86A467 <7 5 4 3>

is it disabled too?

It came with Intel Power Gadget

As well there are kexts for scanners, WiFi, printers etc.

Point made; do all kexts operate on the same level within the OS? As in are there system kexts that operate differently and on a higher security level than those for hardware components that may possibly be impacted by the absence of something like the T2 Chip? Or would that be a kernel level operation?

 

 

Sent from my iPhone using Tapatalk

Share this post


Link to post
Share on other sites

Apple can ban FakeSMC if he wants but it is not happen.

 

When you look at it Apple gets free R&D for hardware testing and a lot of Hackintoshers use Beta OS so it helps them too!   Not to mention all the software apps that we buy as well.    There are many Apple employees that have hackintosh systems for the same reasons we do ( best available hardware).    

Share this post


Link to post
Share on other sites

T2 seems to be more like a co-processor for the hardware functions. This stuff is controlled by UEFI and OS in our systems like CPU fans, CPU freq,GPU cooling etc...

 

For me Pentium users, there is a problem. AVX support but there is a workaround made by Clover devs so it's not a big deal. macOS works at the same performance as my Windows 10 sometimes even better.

Share this post


Link to post
Share on other sites

My worry is the bit about boot encryption to confirm the authenticity of the machine...sounds a lot like proprietary locks meant to keep people from building a Hackintosh or modify the machine.

 

https://www.google.com/amp/appleinsider.com/articles/17/12/12/imac-pro-debuts-custom-apple-t2-chip-to-handle-secure-boot-password-encryption-more/amp/

 

Also I wouldn’t say Apple “supports Hackintosh” as the very concept violates Apples terms for its Operating System. They disable the use of third party kexts by default, we bypass this in order to make a Hackintosh work.

 

 

Sent from my iPhone using Tapatalk

 

 

 

If you mean SIP, then there is more to it. Other than that, non Apple native kexts could always be installed and used, with verification and authentication. And SIP can be disabled, and enabled. Apple is very much aware of this, Apple made this happen themselves, in fact. 

 

When it comes to Apple wanting Hackintoshing around or not, I don't know if they do. Their EULA is against it, which people "auth sign-on" when clicking "Agree". However, it is debatable whether it is illegal or not, but that is another talk. In the past, Apple has stopped the people from selling hackintoshes. But that is all, as I've heard of. I could understand that Apple might somewhat gain something from the hackintosh communities, as long as they don't decrease the real Macintosh sales rates. 

Share this post


Link to post
Share on other sites

If you mean SIP, then there is more to it. Other than that, non Apple native kexts could always be installed and used, with verification and authentication. And SIP can be disabled, and enabled. Apple is very much aware of this, Apple made this happen themselves, in fact. 

 

When it comes to Apple wanting Hackintoshing around or not, I don't know if they do. Their EULA is against it, which people "auth sign-on" when clicking "Agree". However, it is debatable whether it is illegal or not, but that is another talk. In the past, Apple has stopped the people from selling hackintoshes. But that is all, as I've heard of. I could understand that Apple might somewhat gain something from the hackintosh communities, as long as they don't decrease the real Macintosh sales rates. 

 

They gain market share and sometimes like somebody said we are beta tester for their products. They also gain costumers for AppStore and sometimes they even buy hardware like magic mouse for the Hackintosh.

 

They just like

 

offical: We don't support hackintosh.

 

unoffical: if you want use it, we aren't here to stop you from doing this.

Share this post


Link to post
Share on other sites

This is like a thread of enormous paranoia. Nothing they put into a machine is going to stop you from hacking a PC to run an OS that has the same instruction architecture, because the device can always be emulated because of always having control of the entire system before macOS can ever gain access to anything. In fact both SMC and T2 could be emulated using runtime SMM drivers and not even need another kext, this is a common use of SMM for technologies that are now faster in software than hardware such as legacy controllers like PS/2. There are even TPM emulators in SMM for when the chip is in an add-on or not present at all, or even just to supplement its feature set. coreboot has such an emulator. Basically this chip is just an upgraded SMC it looks like and is because they probably want to included a device that can speed up encryption/decryption through hardware like a TPM, of which it has almost exactly the same features as.

Share this post


Link to post
Share on other sites
Posted (edited)
On 3/21/2018 at 4:02 PM, Download-Fritz said:

1) There is no publicly documented trap'ing on memory access (for MMIO).

2) T2 also embeds the SSD controller and verifies the firmware.

1) Where is the publicly documented anything for any apple device/hardware? Where's the SMC reference? The chip can be reversed engineered through attacks on an actual iMac Pro, the same way that SMC was. Pretty sure there is going to be a driver or part of the kernel, which will be able to be disassembled. There must be some sort of MMIO because it incorporates controllers that wouldn't work without MMIO, like the SSD controller you mention next.

2) This is only a problem when they no longer support any mac without a T2 chip, then the same method could be applied, SMM can perform an emulation layer over the chipset. This will result in extreme performance degradation as the amount of calls needed for reading/writing from a disk would almost certainly be unsustainable with the overhead of thunking into SMM. More below.

On 3/21/2018 at 9:06 PM, UefiBooter said:

Unfortunately the overhead of switching in and out of SMM can be quite costly performance wise.

The cost will be minimal because how often do you think this will be needed? This overhead already exists in PC firmware, for god sakes, almost all important things like power management and the like are already done in SMM. This doesn't need to do much other then create a fake device for emulation. The higher functions could still just be a runtime driver, since most likely these will be wrappers around just sending it to through SMM. The SSD controller component on the other hand is the real issue, but I image that other SSD drivers could just be written.......? What about thunderbolt external SSDs with PCIe-to-SATA controllers embedded? They no longer going to work?

EDIT: Also I see multiple different weird things. I see manages SSD disks and SSD controller in different places by Apple. Is this really a controller or some sort of mechanism to help SSD speed?

Edited by apianti

Share this post


Link to post
Share on other sites
1 minute ago, apianti said:

1) Where is the publicly documented anything for any apple device/hardware? Where's the SMC reference? The chip can be reversed engineered through attacks on an actual iMac Pro, the same way that SMC was. Pretty sure there is going to be a driver or part of the kernel, which will be able to be disassembled. There must be some sort of MMIO because it incorporates controllers that wouldn't work without MMIO, like the SSD controller you mention next

Why would SMC trap on anything? Better re-read.

Share this post


Link to post
Share on other sites
3 minutes ago, Download-Fritz said:

Why would SMC trap on anything? Better re-read.

Where on Earth did I say that? Because I didn't. I said it was reversed..... 

Share this post


Link to post
Share on other sites
6 hours ago, apianti said:

1) Where is the publicly documented anything for any apple device/hardware? Where's the SMC reference? The chip can be reversed engineered through attacks on an actual iMac Pro, the same way that SMC was. Pretty sure there is going to be a driver or part of the kernel, which will be able to be disassembled. There must be some sort of MMIO because it incorporates controllers that wouldn't work without MMIO, like the SSD controller you mention next.

2) This is only a problem when they no longer support any mac without a T2 chip, then the same method could be applied, SMM can perform an emulation layer over the chipset. This will result in extreme performance degradation as the amount of calls needed for reading/writing from a disk would almost certainly be unsustainable with the overhead of thunking into SMM. More below.

The cost will be minimal because how often do you think this will be needed? This overhead already exists in PC firmware, for god sakes, almost all important things like power management and the like are already done in SMM. This doesn't need to do much other then create a fake device for emulation. The higher functions could still just be a runtime driver, since most likely these will be wrappers around just sending it to through SMM. The SSD controller component on the other hand is the real issue, but I image that other SSD drivers could just be written.......? What about thunderbolt external SSDs with PCIe-to-SATA controllers embedded? They no longer going to work?

EDIT: Also I see multiple different weird things. I see manages SSD disks and SSD controller in different places by Apple. Is this really a controller or some sort of mechanism to help SSD speed?

for the basic SMC keys its fine as you point out they're read very rarely, but trying to implement the monitoring stuff which is constantly probed mac os experiences timing issues due to the fact that its not aware of delays caused by SMM code.

its already been added to CoreBoot firmware and i ported it to edk2 IoTrap protocol, but this is poorly implemented in firmwares

Share this post


Link to post
Share on other sites
3 hours ago, UefiBooter said:

for the basic SMC keys its fine as you point out they're read very rarely, but trying to implement the monitoring stuff which is constantly probed mac os experiences timing issues due to the fact that its not aware of delays caused by SMM code.

Why would there not be delays? Does communicating with the SMC/T2 chip itself not have overhead? Is it entirely real-time and that's always going to be relied on? I very much doubt that, especially since the T2 chip supposedly has the SSD controller built in. Otherwise, you're saying that if there are requests for a bunch of SSD, PM, and Monitoring actions, that the requests will all come back in a real-time predictable way? I think that Apple might be touting that break-through a lot more than anything else in that case. The chip would just be replaced by something else, emulation, it may be slightly slower but still produces the same end result. You're also forgetting that you don't necessarily need to thunk to SMM for every feature that needs emulated it could just be runtime. 

3 hours ago, UefiBooter said:

its already been added to CoreBoot firmware and i ported it to edk2 IoTrap protocol, but this is poorly implemented in firmwares

I don't know what you mean by this, but what is poorly implemented in firmwares? And you can always reimplement something....

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now


  • Recently Browsing   0 members

    No registered users viewing this page.



×