- Joined
- Dec 3, 2010
- Messages
- 460
- Motherboard
- Gigabyte GA-H55M-S2V
- CPU
- Intel i3-530
- Graphics
- HIS HD 6570
- Mac
- Mobile Phone
What's New
As many of you already know, OS X 10.9 Mavericks has added a new security feature [PDF] which will affect all hackintoshers: signed kernel extensions enforced by the system. Apple has recommended [PDF] that all kernel extension developers join the Mac Development Program and request a kernel extension signing certificate from them, and sign all future extensions. While Mavericks is a transitional release, users trying to load unsigned or invalid kernel extensions will see a warning message while the kernel cache is being built, explaining that the extension is unsigned.
Signed Kexts
Any signed code on OS X is considered "sealed"--it cannot be modified without invalidating the signature, and this includes any bundle resources, like Info.plist. While any digital certificate marked Trusted in the System keychain can be used to sign a binary or bundle (app, kext, plugin...), only certain certificates can be used in certain situations, like signed kexts. Besides verifying the integrity of a signature, OS X applies "code requirements", simple rules designed to further restrict who can do what. In the case of signed kexts Apple checks
That is, it must either be a genuine Apple signature, or a signature from a certificate in the Developer program, with two extra extensions, 6.1.13 (Developer ID execute) and 6.1.18 (Developer ID kext). The OID 1.2.840.113635 is Apple's company prefix, and the rest of the OID describes what specific property must exist in certificate "leaf" (the signing certificate) to allow the kernel extension to load. This means that a valid, signed kernel extension can only be created with a certificate provided by Apple as part of their $99/yr Developer program, and additionally that interested parties must fill out a special form explaining why they require the certificate; kext certificates are only provided upon request and approval.
Other Restrictions
From the PDF above, all kext development on Mavericks is done with the LLVM compiler (GCC is gone), with a "new" directory set aside for third party extensions: /Library/Extensions. Over time, Apple wants everyone out of /System, sort of like C:\Windows--it's for the OS only. All systemwide plugins and modifications must move to /Library, and /L/E will now be watched by the `kextd` process for kexts like /S/L/E was, with the exception that only fully-compliant kexts will be loaded from there going forward. If a signed kernel extension is loaded successfully from /L/E, it was declared valid by `kextd`. During the transition period /S/L/E will allow some unsigned kexts, but /L/E is strict.
For those targeting more than one version of OS X there is another wrinkle: only signatures produced on 10.8.3+ are considered valid on Mavericks, and those signed kexts will not load on 10.7.5 and earlier. Apple encourages developers to produce both signed and unsigned versions, installing the signed to /L/E, and the unsigned to /S/L/E. You must make sure the signed /L/E kext contains a higher version number so it will be loaded.
Exceptions
Despite the warning message, nearly all extant third party kexts are mentioned in a signed kext provided by Apple, AppleKextExcludeList, which contains two lists called "OSKextExcludeList" "OSKextSigExceptionList". The Exclude list currently only contains a few VMware kexts, not surprising since they were mentioned by name during the Mavericks beta period as being problematic. The Exception list however contains every unsigned third party kext known to Apple, including all hackintoshing kexts, along with their versions. This kernel extension allows the kexts it knows about to escape the digital signature requirements, so long as they match the version listed. Exceptions don't produce warnings when loaded, but will be logged to the Console:
What to do
So how do hackintoshers continue to use their machines? Though the Exception list will cover most cases during the initial transition period, where do we go from here?
First, I should say here that I think kext signing is a Good Thing. It means more security for all OS X users, even hackintoshers, and prevents malicious code from loading in the most priviledged space (the kernel) without permission. Those who follow security bugs already know there are plenty of ways to achieve privilege escalation in a modern "secure" operating system, and closing one more door (unsigned kexts) makes your machine that much harder to break. Windows has already had driver signing for a while, and now it's OS X's turn, but what do hackintoshers do?
All capable kext developers should acquire a certificate from Apple if they can, first. This is the best protection, and there should be no reason to reject "legitimate" kexts built from open or the developer's own private source, like Lnx2mac, GenericXHCI, AtherosL1c, etc. All of these kexts serve a legitimate purpose and enable novel hardware to run on a Mac. There is an added responsibility to ensure these kexts match against the largest possible number of models they support, so developers should ensure their IONameMatch, IOPCIMatch, etc cast as wide a net as possible to prevent unnecessary Info.plist edits.
Second, injectors ("codeless kexts" as named by Apple) may also qualify for certificates, though this is more at Apple's discretion.
And then what?
This leaves other injectors and "illegitimate" kexts, those which subvert Apple's walled garden ecosystem, the prime candidate being FakeSMC which enables hackintoshing in the first place. Others may feel that this is Apple's way of cracking down, but I don't see it that way. At the very least they've made an attempt to secure their operating system, and yes, this will catch other groups in the crosshairs. Kozlek, the active developer of FakeSMC, has apparently acquired a certificate from Apple, but I'm skeptical of the outcome. Certainly I wouldn't want to force their hands to make a decision either way, hackintosh or no hackintosh, so I have come up with what I feel is a more equitable solution. Apple doesn't have to explicitly allow or disallow FakeSMC, we find a way around their approval which still provides users with the security of signed kexts: Gatebreak.
I won't be discussing Gatebreak on a technical level here, but suffice it to say it simply and elegantly removes one requirement above, that the certificates must originate from Apple. Without this restriction any user who explicitly adds a certificate as Trusted to the System keychain gives their consent to load a given kernel extension signed with that certificate. The kext must still be untampered and valid, but burden is now on the user to determine the legitimacy of a kext and Trust it.
There is still one more wrinkle here, that even if an open source kext developer posts their source and a signed binary copy (no one should ever post a private certificate key, for any reason), the kernel extension still cannot be modified, even by a user. While it's true that a user could simply re-sign any kext with a certificate they created on their own machine and Trusted, this would mean the death of interoperability: every technically-inclined user's machine would contain kexts usable only by them, and without marking the certificate trusted first, would be unusable even when reinstalling or upgrading.
Look at the NVRAM
To solve this problem, I have posted another solution: NVRAM "user preferences" for kernel extensions. If an Info.plist cannot be modified because it is signed, there is another way of getting "user preferences" into a kernel extension when it loads: reading the NVRAM. Certainly this solution cannot fix an issue like a bad IOPCIMatch, it will only work once the kext is loaded; however it provides an elegant solution to the matter of preferences like "smc-compatible" in FakeSMC, or the REV SMC key which dictates the system's SMC version.
At the simplest level, hackintoshers using Chimera/Chameleon with FileNVRAM can save kext preferences to the NVRAM using the `nvram` utility in Terminal for use with any kext which supports this feature. A special version of FakeSMC is bundled with Gatebreak which allows any configurable property to be modified at boot time.
Not only does this allow any sort of modification (I suggest kext developers only allow property overrides, but this is not a rule), but it also means these preferences can be scripted and exist separate from the kexts themselves. If a preference causes issues, just remove it from the NVRAM. Don't remember what you modified? just run `nvram -x -p` in Terminal. Want to send your friend the same preferences you used? save the output of the previous command and tell them to run `nvram -x -f <file>` where <file> is wherever they saved the output.
In this way kexts remain tunable, but without breaking their seals and while making things simpler in the future. I hope all kext developers will implement something similar soon, where necessary.
As many of you already know, OS X 10.9 Mavericks has added a new security feature [PDF] which will affect all hackintoshers: signed kernel extensions enforced by the system. Apple has recommended [PDF] that all kernel extension developers join the Mac Development Program and request a kernel extension signing certificate from them, and sign all future extensions. While Mavericks is a transitional release, users trying to load unsigned or invalid kernel extensions will see a warning message while the kernel cache is being built, explaining that the extension is unsigned.
Signed Kexts
Any signed code on OS X is considered "sealed"--it cannot be modified without invalidating the signature, and this includes any bundle resources, like Info.plist. While any digital certificate marked Trusted in the System keychain can be used to sign a binary or bundle (app, kext, plugin...), only certain certificates can be used in certain situations, like signed kexts. Besides verifying the integrity of a signature, OS X applies "code requirements", simple rules designed to further restrict who can do what. In the case of signed kexts Apple checks
Code:
anchor apple
anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] and certificate leaf[field.1.2.840.113635.100.6.1.13] and certificate leaf[field.1.2.840.113635.100.6.1.18]Other Restrictions
From the PDF above, all kext development on Mavericks is done with the LLVM compiler (GCC is gone), with a "new" directory set aside for third party extensions: /Library/Extensions. Over time, Apple wants everyone out of /System, sort of like C:\Windows--it's for the OS only. All systemwide plugins and modifications must move to /Library, and /L/E will now be watched by the `kextd` process for kexts like /S/L/E was, with the exception that only fully-compliant kexts will be loaded from there going forward. If a signed kernel extension is loaded successfully from /L/E, it was declared valid by `kextd`. During the transition period /S/L/E will allow some unsigned kexts, but /L/E is strict.
For those targeting more than one version of OS X there is another wrinkle: only signatures produced on 10.8.3+ are considered valid on Mavericks, and those signed kexts will not load on 10.7.5 and earlier. Apple encourages developers to produce both signed and unsigned versions, installing the signed to /L/E, and the unsigned to /S/L/E. You must make sure the signed /L/E kext contains a higher version number so it will be loaded.
Exceptions
Despite the warning message, nearly all extant third party kexts are mentioned in a signed kext provided by Apple, AppleKextExcludeList, which contains two lists called "OSKextExcludeList" "OSKextSigExceptionList". The Exclude list currently only contains a few VMware kexts, not surprising since they were mentioned by name during the Mavericks beta period as being problematic. The Exception list however contains every unsigned third party kext known to Apple, including all hackintoshing kexts, along with their versions. This kernel extension allows the kexts it knows about to escape the digital signature requirements, so long as they match the version listed. Exceptions don't produce warnings when loaded, but will be logged to the Console:
Code:
Excluded Kext Notification
%s is in exclude list; omitting.
com.apple.driver.KextExcludeList
Warning: %s could not find com.apple.driver.KextExcludeList
isInExceptionList
OSKextSigExceptionList
%s could not get bundleID
%s could not get kextVers
kext %@ %lld is in exception list, allowing to loadWhat to do
So how do hackintoshers continue to use their machines? Though the Exception list will cover most cases during the initial transition period, where do we go from here?
First, I should say here that I think kext signing is a Good Thing. It means more security for all OS X users, even hackintoshers, and prevents malicious code from loading in the most priviledged space (the kernel) without permission. Those who follow security bugs already know there are plenty of ways to achieve privilege escalation in a modern "secure" operating system, and closing one more door (unsigned kexts) makes your machine that much harder to break. Windows has already had driver signing for a while, and now it's OS X's turn, but what do hackintoshers do?
All capable kext developers should acquire a certificate from Apple if they can, first. This is the best protection, and there should be no reason to reject "legitimate" kexts built from open or the developer's own private source, like Lnx2mac, GenericXHCI, AtherosL1c, etc. All of these kexts serve a legitimate purpose and enable novel hardware to run on a Mac. There is an added responsibility to ensure these kexts match against the largest possible number of models they support, so developers should ensure their IONameMatch, IOPCIMatch, etc cast as wide a net as possible to prevent unnecessary Info.plist edits.
Second, injectors ("codeless kexts" as named by Apple) may also qualify for certificates, though this is more at Apple's discretion.
And then what?
This leaves other injectors and "illegitimate" kexts, those which subvert Apple's walled garden ecosystem, the prime candidate being FakeSMC which enables hackintoshing in the first place. Others may feel that this is Apple's way of cracking down, but I don't see it that way. At the very least they've made an attempt to secure their operating system, and yes, this will catch other groups in the crosshairs. Kozlek, the active developer of FakeSMC, has apparently acquired a certificate from Apple, but I'm skeptical of the outcome. Certainly I wouldn't want to force their hands to make a decision either way, hackintosh or no hackintosh, so I have come up with what I feel is a more equitable solution. Apple doesn't have to explicitly allow or disallow FakeSMC, we find a way around their approval which still provides users with the security of signed kexts: Gatebreak.
I won't be discussing Gatebreak on a technical level here, but suffice it to say it simply and elegantly removes one requirement above, that the certificates must originate from Apple. Without this restriction any user who explicitly adds a certificate as Trusted to the System keychain gives their consent to load a given kernel extension signed with that certificate. The kext must still be untampered and valid, but burden is now on the user to determine the legitimacy of a kext and Trust it.
There is still one more wrinkle here, that even if an open source kext developer posts their source and a signed binary copy (no one should ever post a private certificate key, for any reason), the kernel extension still cannot be modified, even by a user. While it's true that a user could simply re-sign any kext with a certificate they created on their own machine and Trusted, this would mean the death of interoperability: every technically-inclined user's machine would contain kexts usable only by them, and without marking the certificate trusted first, would be unusable even when reinstalling or upgrading.
Look at the NVRAM
To solve this problem, I have posted another solution: NVRAM "user preferences" for kernel extensions. If an Info.plist cannot be modified because it is signed, there is another way of getting "user preferences" into a kernel extension when it loads: reading the NVRAM. Certainly this solution cannot fix an issue like a bad IOPCIMatch, it will only work once the kext is loaded; however it provides an elegant solution to the matter of preferences like "smc-compatible" in FakeSMC, or the REV SMC key which dictates the system's SMC version.
At the simplest level, hackintoshers using Chimera/Chameleon with FileNVRAM can save kext preferences to the NVRAM using the `nvram` utility in Terminal for use with any kext which supports this feature. A special version of FakeSMC is bundled with Gatebreak which allows any configurable property to be modified at boot time.
Not only does this allow any sort of modification (I suggest kext developers only allow property overrides, but this is not a rule), but it also means these preferences can be scripted and exist separate from the kexts themselves. If a preference causes issues, just remove it from the NVRAM. Don't remember what you modified? just run `nvram -x -p` in Terminal. Want to send your friend the same preferences you used? save the output of the previous command and tell them to run `nvram -x -f <file>` where <file> is wherever they saved the output.
In this way kexts remain tunable, but without breaking their seals and while making things simpler in the future. I hope all kext developers will implement something similar soon, where necessary.
