Contribute
Register

What's New in Kext Development

SJ_UnderWater

Moderator
Joined
Dec 3, 2010
Messages
707
Motherboard
Gigabyte GA-H55M-S2V
CPU
Intel i3-530
Graphics
HIS HD 6570
Mac
iMac
Classic Mac
Mobile Phone
Android
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
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]
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:
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 load
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.
 

Attachments

Joined
Aug 19, 2010
Messages
533
Motherboard
GA-Z390 Designare
CPU
i7 9900K
Graphics
UHD630 & Radeon VII
Mac
MacBook Air, MacBook Pro, Mac mini, Mac Pro
Mobile Phone
iOS
Awsome read,
Thanks SJ.

It specifically cleared up some things I had been wondering about. Frankly i am a bit disappointed that Apple policy is to require certificates come from them. I was under the impression, and hoping, that any valid Dev account could sign their own kexts. Frankly, with OS X now being free, I thought it was very appropriate that every hack user basically be forced to get a dev account for $100 / year. In fact the cost of OS X has been too low for a long time (assuming you don't pay for it via the premium prices built into mac hardware), and $100 / year would at least go further into paying apple something for the great OS we use.

That said i love the fileNVRAM idea and, maybe i am wrong about this, but see it as also a way to transfer some kext settings from kernel flags to nvram setting. I think that will be cleaner if its the case. Looking at for instance genericusbxhci for instance.

Thanks for everything,
g\
 
Joined
Feb 18, 2012
Messages
10
Motherboard
ECS B75H2-AM
CPU
i3 2100
Graphics
Zotac Gt-730
Mobile Phone
Android, iOS
ouch... another cat and mouse scene :D
 
Joined
Nov 25, 2010
Messages
741
Motherboard
gigabyte ga-b75m-d3v
CPU
3350p
Graphics
galaxy gt 640
Mac
MacBook
Classic Mac
Mobile Phone
Other
Thanks SJ..!!
I have used a Rosewill Easy n1 USB wireless for ages.
It worked on 10.8.3
No luck on Mavericks.
I will check and see if I get warning on boot about KEXT.
The Ralink program will not run.
Hopefully Ralink will update. Possibly one of the scenarios you mentioned may be the problem.

Your research and proposals are very useful.
Hopefully my next Hackintosh will not have an Apple motherboard plus my parts.
 
Joined
Feb 20, 2012
Messages
5
Motherboard
GA-Z370P D3
CPU
i3-8100
Graphics
UHD 630
What about loading kexts from /Extra/Extensions? Do these also have to be signed? Thanks.
 

SJ_UnderWater

Moderator
Joined
Dec 3, 2010
Messages
707
Motherboard
Gigabyte GA-H55M-S2V
CPU
Intel i3-530
Graphics
HIS HD 6570
Mac
iMac
Classic Mac
Mobile Phone
Android
/E/E is not known to `kextd`, that's a Chimera/Chameleon feature, so it doesn't count.
 
Joined
Feb 20, 2012
Messages
5
Motherboard
GA-Z370P D3
CPU
i3-8100
Graphics
UHD 630
So they don't need to be signed? Excellent. That seems to fit my experience, installing Mavericks for the first time today.
 
Top