I think it will interesting to see how Apple positions its new products (price/performance...especially GPU), and if they decide to go after any new market segments. Both of these could either decrease (or increase) the incentive to consider a Hackintosh in the first place...
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Is ARM the death knell for the hackintosh?
- Thread starter glenthompson
- Start date
- Sort by reaction score
I am awaiting the release of the RDNA2 GPUs so I can build a Ryzentosh:
Crosshair VIII Impact mDTX mobo
3900X CPU - 12-core / 24-thread
32GB RAM - 2 @ 16GB DIMMs - 3600/16.16.16.36 - Samsung b-die
2 @ 1TB NVMe SSDs - PCIe Gen4 x4
750W Platinum-rated SFX PSU
Something to tide me over until Apple silicon is more firmly entrenched...
Crosshair VIII Impact mDTX mobo
3900X CPU - 12-core / 24-thread
32GB RAM - 2 @ 16GB DIMMs - 3600/16.16.16.36 - Samsung b-die
2 @ 1TB NVMe SSDs - PCIe Gen4 x4
750W Platinum-rated SFX PSU
Something to tide me over until Apple silicon is more firmly entrenched...
Makes sense — I suppose that would happen ~6 years after the last Intel Mac is released, at which point they could make their OS's AS-only.
The general motivation for making a Hackintosh is to get more power for less $. Given this, if the AS chips are so fast that a Mac can equal the general performance of a comparably-priced high-end Hackintosh, that motivation will go away. Whether it can remains to be seen.
The more specific motivation for making a Hackintosh is to customize the machine to your needs. For instance, suppose you are doing development work that benefits from a dGPU that specifically excels at FP64 (e.g., the Radeon VII). So here, if the GPU performance of a comparably-priced Mac equals that of a Hackintosh with a specialized high-end GPU in its area of strength, this motivation will also go away. But that seems much less likely.
The more specific motivation for making a Hackintosh is to customize the machine to your needs. For instance, suppose you are doing development work that benefits from a dGPU that specifically excels at FP64 (e.g., the Radeon VII). So here, if the GPU performance of a comparably-priced Mac equals that of a Hackintosh with a specialized high-end GPU in its area of strength, this motivation will also go away. But that seems much less likely.
Don't forget being able to replace RAM/Storage as you wish, from whom you wish. Some Mac desktops would be perfect for some Hackintosh users if they allowed that, but alas...
Can't really see Apple relaxing on their practices unless forced, so those people are screwed I guess.
Can't really see Apple relaxing on their practices unless forced, so those people are screwed I guess.
The curve for the hackintosh peaks with the availability of drivers for new hardware. Those drivers will dry up for hardware that is newer than the last released Intel Macs. The two things that kill a hackintosh are lack of Wifi and unsupported graphics. If Intel 10th gen processors are the last iGPU supported by Intel macOS then later generations of Intel CPUs are unlikely to support the iGPU under macOS.
It is isn't just "new" Intel chips . Two major things going on.
First, almost all of the current drivers are going to be obsoleted. Not just on ARM ( because didn't exist before), but on Intel also. All the current kernel extensions are being phased out. that means were hackintosh would track what Apple and/or third-party-for-macOS drivers with the same "generic" hardware that Apple bought for Macs would fall by the wayside ( that whole archive of stuff Apple did before will disappear).
Apple (and third parties) will write new stuff for the currently actively sold components, but some stuff will be "garbage collected" away. Apple is basically asking 3rd party drivers vendors ( and Apple driver ) teams to put in a lot of work. That is probably going to cause some hardware to get dropped sooner rather than later.
[ Thunderbolt 4 and PCI-e slots in a future Mac Pro should keep some baseline of 3rd party driver work going. Plus some Apple covers of parts outside of those highly custom parts used internally to future Macs. If Intel doesn't shoot themselves completely in the foot with discrete GPUs there may be some hope on the "future" Intel GPU front. ]
Second, Apple may be dropping UEFI. If they do then that is another wedge for firmware/drivers for the new Apple kernel environment will push older stuff out. ( and will have impact on newer stuff. ) But more directly all the bootloaders that are built to run on top of UEFI will probably have hit some real show stopper issues.
An open kernel provides many avenues for attack vectors to hit. Apple has been on a multi-year strategy to close off the kernel to third parties through SIP, kernel driver signing, etc, culminating in closing off the kernel driver loading API completely. It is possible to link any drivers into the kernel directly so it solves that issue. Third party uses for the kernel can fall into various buckets like virtualization, third party cards, and the like. Virtualization drivers are solved by switching to ARM where no virtualization drivers will be supported. All hooks to support that will come via the HV FW. Apple has also been doing this strategy for all manner of prior requirements to run a driver in the kernel. Kernel programming is a dying art. Even the net filter has user land hooks now.
Third party cards will only be supported on the 'high end' systems like the ARM MacPro. I think this is where it's headed by different versions of the kernel of Mac OS for the ARM. Consumer will not support kernel driver loading at all but there will be limited support on the professional Macs not bought by the unwashed masses.
This is where HW RoT comes in. The kernel will be signed with keys that are fused into Apple Silicon so you can't load unsigned versions of the OS. This is what Apple was alluding to in their WWDC presentation. The boot loader is immaterial as you can't fiddle with it now. In essence, there will be bootstrap code which is signed, that loads the boot loader which is signed, which loads the signed OS. Each phase of loading code is signed with the private key and hash verified by the fused public key in Apple Silicon.
I'd expect only a whitelist of vendors will be allowed to sign their drivers for higher end systems. Lowerend systems will no longer have the ability to load any type of driver after kernel is instantiated by the boot loader.
Don't get me wrong; as far as desktop CPUs go, I'm an AMD fanboy through and through. But you're going to have substantially more headache building an AMD Hackintosh. If you know that already and are cool with that, then hat's off to you. Just want to make sure you know that going in; AMD and Intel are not as interchangable for Hackintoshing as they are for building a generic Windows or Linux PC.
Apple won't be dropping UEFI on Intel Macs. That element won't change. They're likely dropping it on Apple Silicon Macs, but Hackintoshing was only ever based on using generic x86-64 PCs to run Intel Mac operating system releases anyway. Getting Apple Silicon releases of macOS to run on third party ARM64 hardware was never realistically in the cards. Just as getting Mac OS X to run on third party PowerPC boxes in the early half of the '00s was never realistically possible.
I wouldn't be so quick to assume that expansion cards will be limited to the Mac Pro. Just because the future of eGPUs on Apple Silicon Macs is uncertain, doesn't mean that Thunderbolt is going away. Users of non-Mac Pro Macs may still want to attach an expansion card to, say, their Apple Silicon based 16" MacBook Pro via a Thunderbolt 3/4 external chassis. Whatever changes coming in terms of drivers brought about by deprecating KEXTs don't necessarily change that.
On the latter, errr no. Linking isn't going to "solve" the problem. Apple is kicking some (most ) of their drivers out of the kernel also. Once the "back door" for kernel extensions is permanently closed, the evolved kernel is going to be different. Slapping some 'duck tape' around an extension and binding it t other kernel isn't necessarily going to get it initialized correctly. You can wave hands and say how going to jam the kernel extension loading back into a hacked kernel too in addition to linking. At that point really talking about a substantively forked version of macOS. Not really a "hackintosh" that is trying to run a clean macOS.
Kicking most of the stuff out of the kernel is similar to the transition between original Mac OS (up through 7-9 ) and macOS X (10) change from no process memory isolation/protection and protected (via virtual memory addressing) . (and with co-operative multi tasking where apps voluntary gave up control explicit at the "right time" ) . Drivers aren't technically being kicked up to userland. It is still a privileged mode that required signed/authorized approval. They are being moved to a space in between where only have a slice of the memory space that belongs to the device they are in charge of "driving". There isn't really a good reason with modern IOMMU that the USB driver needs direct access to the same I/O memory space as the GPU ( and vice versa).
Going to drivers that primarily depend upon IOMMU support is hardly "no virtualization drivers". Managed ( 'virtual' ) addressing is being applied here.
The key here is not firmware (FW) , it is the hardware IOMMU support in the processor. Yes there is a layer that the kernel implements on top of that. The x86-64 Intel chips of Vt-d (IOMMU) support are kicking the kernel extensions out too. It isn't Apple Silicon specific. It is more a kernel designed in the 2010's era technology specific to what is common on processors in that era and into the future.
The basic concept of the technology has be common on 'big iron' for multiple decades. It has made its want down to pervasive at the "personal computer" level now.
Not so much a dying art as much as don't need to let in the untrained and inattentive to detail. Handing out the Unix root password to every user isn't necessary. Neither is stuffing lots of extra stuff into the kernel.
Probably not.
1. All Macs probably will come with an Apple GPU and apple defined minimal I/O ports. As far as getting a boot environment up and running with a display, Apple will have a complete set of stuff. So bootfirmare wise it will just run. ( that probably includes the Mac Pro also. Get a "good enough" to drive 4 Thunderbolt 4 ports (four 4K displays for 2D workloads. ) . A small expansion into minimalistic external booting for standard NVM-e drives and basically done.
[ There are some corner cases like SoftRAID who have managed to get minimal drivers stuffed into the early boot environment support. But it is unlikely they will be 'special cased' into Mac Pro firmware and not 'special cased' into the rest. Probably in or out across the whole line up. ]
2. Once at the process of loading drivers from the MacOS instance drive then Thunderbolt means there can be PCI-e slots hanging off of a non Mac Pro also. Why there would be a major difference in the driver loading process isn't well grounded.
It is the drivers for the cards that will be the major gating issue (not the Macs themselves). Apple is making everybody rewrite drivers. Some vendors won't. And even those that do some won't extend the support back to older products that don't have R&D funding attached to them anymore. That is going to be the major drop off.
There is still going to be driver loading. It is just not into the completely unprotected kernel space.
Err no. At least in the hackintosh space. At Hackintosh doesn't necessarily care about Root of Trust.
Apple signatures.... just ignore them and move on. That's the thing about Root of trust. The stuff on top of the trusted foundation doesn't particularly go back and validate the foundation but it is supposed to have been validated at that point before the layer on top ever got started. Once something else is underneath then don't really have a trusted root layer. The lower signature checks can all be skipped if stick something else in at the lower levels.
You are talking there about a Mac. On a hackintosh there isn't no Apple secure enclave. The ability for a Window 10 standard hardware PC to run Windows 10 or Linux isn't a huge feat on that hard. Just boot with the UEFI process that is already there. Getting Windows to run on a piece of hardware isn't major part of being a Hackintoush; getting macOS to run is.
Correct in so far at some point the Hackintosh probably won't be able to run anything connected TouchID, FaceID , ApplePay , Siri ( or any highly optimized Apple AI/ML app that is 100% dependent upon Apple Neural cores being present) , etc. When Apple drops all non Apple Silicon support there is going to be a substantial amount of non ARM stuff present in every Mac which will have hooks into a substantive number of features.
And if the kernel does any kind of sanity check ( hey since secure enclave is required now and there is no secure enclave ... abort , not on a licensed system. ), then Hackintosh will need a hacked kernel bundle to get around that also. The signatures aren't going to be major issue. The missing-in-action hardware is. ( in part because Apple isn't going to sell that to anyone.)
MacOS may be the boot loader long term. The Apple Silicon (AS) system will likely have an early boot stage with iBoot. The T2 systems do. In the T2 systems the iBoot hands off to UEFI. The AS iboot might hand off to the "System Recovery" volume in a boot support mode. It loads that ultra minimalistic macOS instance in handle external boot, volume selection, and the standard login screen stuff (filevault / regular ).
Just would need drivers that were bundled and didn't have major UEFI assumptions built into them. Again nothing about "high end" vs "low end" macs segmentation.
For developers who are trying to get their drivers qualified for inclusion in the "System Recovery" mode, all Apple would need is a way for those devs to attach a "data" volume to the system recovery volume for their driver. It would necessarily be a mode that Mac Pro could do and a MacBook Air couldn't. It is just a relatively small allocation of disk space.
The normal mode for kernel extension drivers now is to get them signed. That System extensions have to nominally signed isn't really "new". A secure boot parameter that says unsigned System Extensions would be loaded wouldn't really be all that "new". ( or need to be restricted to only a subset of macs. )
But at some point all of the Intel Macs left will be T2. Not that Apple is likely to sink that kind of work into a major T2 system upgrade (and drop booting into old macOS instances ) , but those probably could be dumped ( since the T2 basically feeds the CPU a copy of something to get started with. ). T2's all start off on iBoot and only switch to UEFI as part of the transition.
Yes, In the PowerPC era Apple built their own I/O controllers (Southbridge . PCH in Intel current terminology). Apple didn't write driver support for the stuff that was suspose to be standard for IBM/Motorols chips. With Intel x86 family of chips the accompanying chipset was something everyone who picked the specific Intel CPU had to deal with ; including Apple.
Where Apple is going chipset wise might have some partial coverage if they go path AMD did and just license something from ASMedia and tweak it. That could end up close enough to being in the practical range. If it is all totally custom (and no other way to boot any probe or get a UEFI 'metadata grab" on the hardware then drifts more into the impractical range. Tons of time and effort with very low pay off ( because extremely few want to pay substantive amounts for hacks ) .
Apple's secure element , TouchID/FaceID , and other non ARM stuff buried in the SoC. All of that basically has to be tap danced around. Technically not impossible to work around , but even bigger "to do" list work to even get booted.
However, these days some folks have more time, money to throw at in-practical things. With deep enough hacked kernel and Cirque de Soliel contortions someone could get a system into a "happens to work" state if don't blow on it too hard.
With Thunderbolt there should be some USB controllers, SATA controllers , NVM-e support etc left in the system though.
Notion that Thunderbolt is going away? GPUs really don't have anything substantive to do with "inferencing the future " on that issue:
'... In a statement offered to TechCrunch, the company restated its commitment to connection it’s been so invested in over the past several years, noting,
“Over a decade ago, Apple partnered with Intel to design and develop Thunderbolt, and today our customers enjoy the speed and flexibility it brings to every Mac. We remain committed to the future of Thunderbolt and will support it in Macs with Apple silicon.” ... '
Apple says it’s ‘committed’ to supporting Thunderbolt on new Macs after Intel details latest version | TechCrunch
Earlier today, Intel offered some key insight into Thunderbolt 4, following an initial unveiling at CES back in January. The latest version of the
techcrunch.com
There is more on Thunderbolt ports than just eGPUs. [ In fact, most "eGPUs" are technically external PCI-e slot expansion boxes. A variety of cards can be placed in them. ]. However, not sure though how Apple 'supports' Thunderbolt and but also nukes GPUs on Thunderbolt ports. The one slide from the 2020 WWDC on GPU support isn't necessarily a fixed in stone statement of the future 1-2 years from now.
[ Thunderbolt support is likely going to be bumping at the beginning though. The DTK doesn't have any Thunderbolt ports. So developers with only access to those can't work on testing drivers with Thunderbolt (hot plug PCI-e ) support in them at this point. So obviously, most of those won't be working day one of the product transition. ]
There is also no certain closure on embedded dGPU in Mac systems ( e.g. MBP 16" , iMac 27" , iMac Pro ). If the Mac Pro is still using a 3rd party dGPU then a desktop level just below that probably will be also (just embedded and not on an add-in-card).
Short term , Apple is probably going to move the iGPU systems over because that is most of the market.
Ahead of Ampere, Nvidia Grows to 80% of Dedicated GPU Market, Analysts Report
COVID-19 may be affecting the market.
Apple needs to cover what Intel covers first with apps that are highly tuned to Apple GPU. The rest can come later as that is not the bulk of the market. ( note: AMD and Nvidia combined don't cover Intel's share in the above graph. )
From the "box with slots" view of the world ( which is where almost all rabid Hackintosh folks are. ), there is a different world view.
Apple doesn't really operate in that world view. (so combining Apple's WWDC 2020 slide with that world view they don't have is probably not a good inference combination. ) Laptops are 70-80% of all macs sold. (and they have already chucked that Nvidia part above with their x86-64 systems without loosing tons of sleep. ) So Apple's initial Apple Silicon SoC efforts are highly likely geared the laptop way. By next June WWDC Apple's slides could have a wider, more complete view of the GPU spectrum on ARM infrastructure Macs (and likely there will still be an Apple GPU in all of them . So none of work at Apple's direction to get busy optimizing for their GPU would have been 'wasted' ).
The notion that Apple is going to permanently chuck every vendor in that second graph out the window is a bit looney. Hard to believe anyone at Apple is drinking that much Cupertino kool-aid. Dropping Nvidia is one thing. Dropping all three would highly likely have major negative consequences. Where Apple is already at is 'hard' .
You know from 1995-1998, Apple authorized other companies to manufacture and sell PowerPC-based Mac clones.
During that era, the Macintosh still relied on the "Old World" Toolbox ROM. It was the Toolbox ROM that made the Mac the Mac, irrespective of the processor that did the computing. Every Mac clone featured an Apple-supplied Toolbox ROM. Mac clones were not clones at all. They were genuine Macintosh computers packaged in different boxes and sold by different OEMs.
Though, it’s fun to think they would license it to certain non-competing companies. Like Nintendo
Primarily because Apple’s solution is more efficient than and out-performs Tegra. But, unlikely their license with ARM even allows that LOL
There will always be someone who will want to try to run ARM macOS on non Apple ARM devices. Determination will decide if they succeed. But most ARM devices are small, mobile, integrated SoC, IoT or in that avenue. Maybe at some point will you have some off the shelf PC builder boxes based on ARM, but I think that there will be no real benefit for now to try to "Armintosh" those. And if the prediction of Apple being the more inexpensive/powerful option, the chances are that the route will go the other way. I think it will be interesting to see what people will do with the new Arm Macs.
Apple is still updating the UEFI firmware on Macs that aren't going to get Big Sur support. They're going to continue to do that until those Macs no longer receive security updates (at the launch of the successor to the successor of Big Sur, no doubt). I suspect that Apple will continue to update both iBoot and the UEFI firmware on T2 Macs until they get their last security updates for their last compatible macOS release.
But that says nothing about Apple using UEFI on Apple Silicon Macs. They'll likely drop support for that because they're not using an architecture that mandates it. They can be as proprietary as they like with Apple Silicon based Mac hardware. When they were playing in Intel's house, they, to a certain extent, needed to play by some of Intel's rules. The T2 allowed them to bend on that considerably, but with Apple Silicon, it's Apple's house and they can call whatever shots they like; rendering the need to conform to the UEFI standard completely moot.
Notion that Thunderbolt is going away? GPUs really don't have anything substantive to do with "inferencing the future " on that issue:
'... In a statement offered to TechCrunch, the company restated its commitment to connection it’s been so invested in over the past several years, noting,
“Over a decade ago, Apple partnered with Intel to design and develop Thunderbolt, and today our customers enjoy the speed and flexibility it brings to every Mac. We remain committed to the future of Thunderbolt and will support it in Macs with Apple silicon.” ... '
Apple says it’s ‘committed’ to supporting Thunderbolt on new Macs after Intel details latest version | TechCrunch
Earlier today, Intel offered some key insight into Thunderbolt 4, following an initial unveiling at CES back in January. The latest version of the
There is more on Thunderbolt ports than just eGPUs. [ In fact, most "eGPUs" are technically external PCI-e slot expansion boxes. A variety of cards can be placed in them. ]. However, not sure though how Apple 'supports' Thunderbolt and but also nukes GPUs on Thunderbolt ports. The one slide from the 2020 WWDC on GPU support isn't necessarily a fixed in stone statement of the future 1-2 years from now.
[ Thunderbolt support is likely going to be bumping at the beginning though. The DTK doesn't have any Thunderbolt ports. So developers with only access to those can't work on testing drivers with Thunderbolt (hot plug PCI-e ) support in them at this point. So obviously, most of those won't be working day one of the product transition. ]
You completely misread what I said. I didn't say Thunderbolt was going away. Apple spokespeople have outright said that it isn't. What I said COULD (as in "I'm not at all sure if it will or won't") go away is eGPU support. I'd hope that Apple could design their systems such that an externally attached AMD GPU could still assist performance of whatever internal GPU they're packing on Apple Silicon Macs, but the fact of the matter is that it may not work that way. And right now, no one has any details on it. Given the work and big deal behind making this possible for Intel Macs, I'd be shocked to see the effort suddenly stop there, but it's completely hard to say. Plus, Apple's tile-deffered rendering approach might render your standard AMD GPU incompatible. I couldn't say.
There pretty much is certain closure on that. Apple pretty much outright stated it in their Apple Silicon architecture overview WWDC2020 video. That said, if their level of performance with their own GPUs (albeit with software optimized for both them and Metal) is on par with the kinds of GPUs you'd find in the 16" MacBook Pro and both sizes of iMac, then they honestly shouldn't need a dGPU as their iGPUs will rival performance and, most importantly, not do so the same kind of wattage cost. The only question then becomes how well can Apple scale that performance up to the Mac Pro.
The new Macs are not just running ARM cores, there are other "cores" in the Apple Silicone. For example the encryption processor. No other chips but Apple chips will have these "other cores".
So yes, for sure you will not have "Hackintosh" after Apple drops support for Intel.
Again the key is the "Apple Silicone" or more than just "ARM".
The "encyption processor" is a "secure element" and even in T1 and T2 Intel Macs, that has always been a processor running the ARM64 instruction set. Given that will more than certainly be in the Apple Silicon SoC (which is also a chip running the ARM64 instruction set), it will still be a processor running the ARM64 instruction set.
Just speculating... if at a very low level, macOS assumes things like the neural engine, the secure enclave and the on chip graphics are there and configured the way they expect them to be configured, then since no other ARM processor has those specific units, that would mean a significant amount of work for any hacker to code around the impediments. Instead of just coding drivers to go between the SAME CPU to different subsystem components, it would be an attempt to recode the instructions that the CPU uses to execute it’s own code, marginally more difficult than what a current hackintosher has to do.
I would say it’s more than likely possible if ONLY because some folks love a challenge and will work on it until they’ve got it working well enough. But, it won’t be anywhere near as easy to implement is a current hackintosh.
I'm gonna suggest that it isn't going to be feasible. Possible? Well, sure, anything is possible. But we've had iPhones for years since Android has come out and I've never heard of any solid attempts to get Android running on an iPhone. Similarly, one would imagine that (assuming decent driver writing happens) iOS would totally scream on something like a high end Pixel, Galaxy S phone, or a OnePlus phone. But Apple surely makes that happening on the hardware front damn-near impossible. I can't imagine that they'll merely be limited by dsmos.kext with the Apple Silicon versions of macOS.
The other thing I wonder, now that you mention it is how easy it will be to install unsupported releases of macOS on Macs that got left out of them. There are whole communities devoted to doing things like getting a 2012 MacBook Pro or iMac to run Big Sur. I wonder if Apple will do anything with Apple Silicon releases of macOS to make this difficult. You can't do this with iOS and iPadOS because the update is specific to the model of device being updated. But I can't fathom them necessarily doing this full-tilt on the macOS side of things. But maybe that's something that they'll eventually do.
Power Computing was the number one clone maker but Motorola and others had a few of their own.
A Power Computing 275 MHz 604e was used to demo Halo originally. The company was made up of employees from APS Tech, Dell, and one other company. They were always pushing the boundaries.
I can't imagine anyone will get ARM-based macOS working as well as they do on Intel.
I think you’re right. Once Apple’s no longer releasing Intel versions of the OS, that MAY be the end of the road for subsequent releases to show up on Intel systems. Again, having said that, I’m sure that some group may make it their sworn duty to look at what all the ARM code is doing (in macOS XX?) and attempt to write Intel versions of all that and even release a tidy little updater. But, effectively a non-event for folks that wanted to simply take macOS and run it on a MUCH faster Intel PC that Apple doesn’t offer.
And, I also think it’s possible that, since the code will be coming from Apple (when performing any upgrades), it’s likely that each “version” of macOS actually consists of a lot of different packages specifically meant for each system to be installed to. I know it works this way on iPadOS and iOS (where the upgrade is sized for the specific device receiving it), so I wouldn’t doubt that it works that way on any future laptop/desktop Apple Silicon systems.
Another question, are there even ARM BYO systems out there?