T2 in new Mac hardware and its impact on virtualizing and running macOS – Role of SMC

In the last few weeks, we have received a lot of inbound questions on the existence of T2 chip in new Apple Mac hardware models and how it impacts the ability to run macOS VMs. In this blog series, we will try to share our knowledge and insights on this topic.

The focus of this first blog is on the role SMC plays in booting macOS and how T2 chip impacts this function. Apple T2 chip can control many aspects of the macOS platform over a single unified bus. One of them is, performing additional firmware validation in a trusted execution environment before supplying it to the chipset for execution. During macOS booting, macOS is accessing the hardware SMC chip to read key validation of the Mac.

In T2 enabled Mac hardware, T2 chip is acting as gatekeeper to SMC. Hackintosh and KVM  based projects, which use Clover, are using the saved key of the SMC key, and bypassing the SMC validation. And, tools like ESXi access to SMC in this hardware is blocked by T2, unable to boot macOS VMs (https://twitter.com/lamw/status/1120368830427959297).

However, any solution that leverages macOS native hypervisor.framework like Anka, can boot macOS VMs without any issues. In this scenario, SMC calls are placed through the hypervisor.framework APIs and T2 is able to pass those onwards.

T2 chip in new Mac hardware not only acts as a gatekeeper during the boot process, but also prevents unauthorized access to internal SSD and Thunderbolt ports. So, even if any tool somehow manages to boot macOS VMs(using saved SMCkeys), it will not have access to the SSD. The workaround would be to use USB or network attached storage which is slow, not scalable and unreliable. More on this in our next blog.

Let us know if you have additional questions/comments in our slack channel.

References – https://www.apple.com/mac/docs/Apple_T2_Security_Chip_Overview.pdf