Devs Make Progress Getting MacOS Venture Running On Unsupported, Decade-Old Macs (arstechnica.com) 20
An anonymous reader quotes a report from Ars Technica: Skirting the official macOS system requirements to run new versions of the software on old, unsupported Macs has a rich history. Tools like XPostFacto and LeopardAssist could help old PowerPC Macs run newer versions of Mac OS X, a tradition kept alive in the modern era by dosdude1's patchers for Sierra, High Sierra, Mojave, and Catalina. For Big Sur and Monterey, the OpenCore Legacy Patcher (OCLP for short) is the best way to get new macOS versions running on old Macs. It's an offshoot of the OpenCore Hackintosh bootloader, and it's updated fairly frequently with new features and fixes and compatibility for newer macOS versions. The OCLP developers have admitted that macOS Ventura support will be tough, but they've made progress in some crucial areas that should keep some older Macs kicking for a little bit longer.
[...] First, while macOS doesn't technically include system files for pre-AVX2 Intel CPUs, Apple's Rosetta 2 software does still include those files, since Rosetta 2 emulates the capabilities of a pre-AVX2 x86 CPU. By extracting and installing those files in Ventura, you can re-enable support on Ivy Bridge and older CPUs without AVX2 instructions. And this week, Grymalyuk showed off another breakthrough: working graphics support on old Metal-capable Macs, including machines as old as the 2014 5K iMac, the 2012 Mac mini, and even the 2008 cheese grater-style Mac Pro tower. The OCLP team still has other challenges to surmount, not least of which will involve automating all of these hacks so that users without a deep technical understanding of macOS's underpinnings can continue to set up and use the bootloader. Grymalyuk still won't speculate about a timeframe for official Ventura support in OCLP. But given the progress that has been made so far, it seems likely that people with 2012-and-newer Macs should still be able to run Ventura on their Macs without giving up graphics acceleration or other important features.
[...] First, while macOS doesn't technically include system files for pre-AVX2 Intel CPUs, Apple's Rosetta 2 software does still include those files, since Rosetta 2 emulates the capabilities of a pre-AVX2 x86 CPU. By extracting and installing those files in Ventura, you can re-enable support on Ivy Bridge and older CPUs without AVX2 instructions. And this week, Grymalyuk showed off another breakthrough: working graphics support on old Metal-capable Macs, including machines as old as the 2014 5K iMac, the 2012 Mac mini, and even the 2008 cheese grater-style Mac Pro tower. The OCLP team still has other challenges to surmount, not least of which will involve automating all of these hacks so that users without a deep technical understanding of macOS's underpinnings can continue to set up and use the bootloader. Grymalyuk still won't speculate about a timeframe for official Ventura support in OCLP. But given the progress that has been made so far, it seems likely that people with 2012-and-newer Macs should still be able to run Ventura on their Macs without giving up graphics acceleration or other important features.
Headline has a typo, security (Score:2)
The link mentions having to disable "library validation" and add kernel boot arguments to disable similar security features to get these (ingenious) bandaids going.
Unfortunate that Apple chose this forced obsolescence route, but perhaps macOS can still
Re: (Score:2)
Re: (Score:2)
I noticed that too. I've had bad LCD screens, failing parts, bad keyboards, design that pushes form over function so far as to break things. The list is endless.
Description of the life of any computer owner. I've had PCs with LCD screens, failing parts, .. but I'll concede the bad keyboards point. As for from over function, a laptop/tablet is a slab, regardless of whether it is branded Apple or anything else. What irritates you about the particular variant of a slab that Apple uses for it's devices? ... Do the rounded corners not give you as painful a jab when you bump into them as the sharp corners on a PC?
Installing a small calculator app or whatever on MacOS is always a minimum of several gigs or more disk space. It's crazy.
No, that's ridiculous hyperbole. Modern apps seem to be ne
Why not just emulate the missing instructions? (Score:3)
I'm assuming they're using a custom kernel anyway. It seems like it would be easier, rather than trying to kludge it together using Rosetta binaries that avoid a particular set of instructions, it might make more sense to trap illegal instructions and hot-patch a jump into a compatibility shim library similar to the way NetBSD-mac68k does software floating-point emulation. That way, it will work for any app, not just apps compiled to run on older CPUs (which newer apps might not be).
Re:Why not just emulate the missing instructions? (Score:4, Insightful)
Why not just emulate the missing instructions?
Because doing that would cause the security theater to come crashing down on top of them in an instant. Modern versions of MacOS use hardware protections similar to Microsoft's Secured-Core PC crap. These "protections" prevent modifications of the boot image and kernel, and various parts of MacOS including the built in apps verify against it. The only way to fake that would be to emulate the entire hardware chip, along with using a valid key from a legit one, with some modifications to the boot verification code to use an alternate verification method that could be controlled by the end user. Needless to say, that requires a ton of effort to pull off. It may happen in the future, but for right now re-using what apple provides is a faster solution. Even if it's not a long term one.
I'm assuming they're using a custom kernel anyway.
Actually per TFA, they are using an offshoot of OpenCore [github.io]. Which is essentially an Initial Program Loader that modifies the preboot environment (Patches ACPI tables, SSDT, installs device drivers, fakes the SMC, etc.) so that Apple's bootloader will run without issue. It can modify the kernel, but the purpose of OpenCore is to get MacOS running without disabling it's security functions. (Which will also break other functions / apps of MacOS if security is disabled and they aren't patched as well.)
it might make more sense to trap illegal instructions and hot-patch a jump into a compatibility shim library similar to the way NetBSD-mac68k does software floating-point emulation.
That assumes that illegal instructions aren't intentionally placed within the binaries for various DRM purposes. If that isn't the case (which is very likely), then they also have to create workarounds to avoid these checks that will break on the next update. As, unlike Apple, a random OSS development team cannot dictate what compatibility shims are "legit". Not to Apple apps, and especially not to third party apps. Someone should send that example to the Right to Repair folks....
That way, it will work for any app, not just apps compiled to run on older CPUs (which newer apps might not be).
Although implementing legit instructions would be useful, (FYI: WINE does this for certain instructions in Windows Apps, so it's not unheard of.), it is time consuming when Apple already provides a solution. Even if it's not a long term one, it will allow the dev team to see if their work is even feasible. If so, they may go back and implement their own instruction emulation at a later point in development. (Probably when Apple decides to deprecate Rosetta II.)
Re: (Score:3)
Why not just emulate the missing instructions?
Because doing that would cause the security theater to come crashing down on top of them in an instant. Modern versions of MacOS use hardware protections similar to Microsoft's Secured-Core PC crap. These "protections" prevent modifications of the boot image and kernel, and various parts of MacOS including the built in apps verify against it.
You mean the "Don't Steal MacOS" kext? Those checks got thoroughly broken fifteen years ago. At the time, I said it would be broken within a month, IIRC, which it turned out was actually too conservative. It was something like two weeks.
The only way to fake that would be to emulate the entire hardware chip, along with using a valid key from a legit one, with some modifications to the boot verification code to use an alternate verification method that could be controlled by the end user. Needless to say, that requires a ton of effort to pull off. It may happen in the future, but for right now re-using what apple provides is a faster solution. Even if it's not a long term one.
I honestly have no idea what you're referring to here. Are you talking about the hardware-based crypto on the boot volume? You know you can turn that off entirely without any misbehavior, right? Or are you talking about the "Don't Steal MacOS" kext, which as I said was
Re: (Score:2)
You mean the "Don't Steal MacOS" kext?
No, I'm referring to the T2 / Apple Enclave chip used by modern Macs in Apple's version of Secure Boot as described by OpenCore here [github.io].
Folks build custom macOS kernels all the time [blogspot.com].
As I already said, using a custom kernel isn't the point of OpenCore.
I guess if your goal is to not have to disable SIP.
It is.
then how are they doing that while running a patched operating system
They aren't. They are patching the preboot memory map and installing firmware hooks to make MacOS satisfied with what it finds. One such firmware hook is a module to fake the SMC, which includes the infamous copyright string that the kext you mentioned earlier checks for. As far as MacOS is concerned
Re: (Score:2)
You mean the "Don't Steal MacOS" kext?
No, I'm referring to the T2 / Apple Enclave chip used by modern Macs in Apple's version of Secure Boot as described by OpenCore here [github.io].
Why would you use this on a device that has a T2 chip? AFAIK, all T2-based machines are natively supported by Ventura.
Anyway, I get your point, that the UEFI firmware signature checks would fail, and anything that explicitly checks to see if the kernel is signed (which probably only affects whether HDCP is shown as supported) will fail unless you figure out how to get the kernel to lie, at which point at least ostensibly you have no trust, but realistically not.
then how are they doing that while running a patched operating system
They aren't. They are patching the preboot memory map and installing firmware hooks to make MacOS satisfied with what it finds. One such firmware hook is a module to fake the SMC, which includes the infamous copyright string that the kext you mentioned earlier checks for. As far as MacOS is concerned the firmware hook looks like a legit hardware device at the appropriate address giving the correct responses. So the check passes and no modification of the kernel is required.
I'm not talking about the SMC. I'm talking a
Apple took the worst parts of NextStep (Score:3)
Re: (Score:3)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
What about the opposite (Score:3, Interesting)
I'd rather they find a way to install and run older MacOS (Mojave) on recent hardware.
I am on MBP 2015 and will continue using it as long as I can, because the next one (which I ordered before they went extinct, sitting here waiting) will run Catalina.
Seems like they're making it overly difficult (Score:2, Interesting)
You can actually run the latest versions of macOS in VBox guests without any problems even on 10+ year-old Macs - just without significant graphics acceleration because... VirtualBox - all you need to do is set the guest's DMI product identifiers to identify itself as a currently supported iMac or Macbook Pro before doing a macOS install.
It's ironic/annoying that you can install High Sierra into a guest and immediately get prompted for updates to Big Sur, Monterey, etc. even though the genuine hardware host
Re:Seems like they're making it overly difficult (Score:5, Informative)
OCLP already supports Big Sur and Monterey on a wide range of unsupported Macs in a relatively straightforward manner. Ventura is a whole new ball game, not even including system files for pre-AVX2 CPUs.
You can't just tweak identifiers to get around that.
Security? (Score:3)
Re: (Score:2)
*"Properly" is relative. As OpenCore requires tailoring it to the specific hardware to be usable. What is "proper" for you is not necessarily "proper" for someone el