Load untrusted kernel extension in macOS Mojave

code-signingkernel-extensionsmojavesip

The Volta application is installed on my MacBook Pro, running macOS 10.14 Mojave.

This app needs a kernel extension to function properly, and said extension does not have the proper code signatures. This means it's necessary to tamper with System Integrity Protection in order to load this extension.

In macOS 10.13 High Sierra, one could run csrutil enable --without kext to partially disable SIP (loading unsigned kexts is allowed, but other protections remain in place). According to Volta's installation instructions, in Mojave one must fully disable SIP, leaving the whole computer unprotected because of one kernel extension.

For reference, this is the output of kextutil -l applied to this extension:

$ sudo kextutil -l /Applications/Volta.app/Contents/Resources/Driver.kext
Untrusted kexts are not allowed
Kext with invalid signature (-67050) denied: /Library/StagedExtensions/Applications/Volta.app/Contents/Resources/0A012E5A-9F74-4E19-9195-535AD692A597.kext
Bundle (/Applications/Volta.app/Contents/Resources/Driver.kext) failed to validate, deleting: /Library/StagedExtensions/Applications/Volta.app/Contents/Resources/0A012E5A-9F74-4E19-9195-535AD692A597.kext
Unable to stage kext (/Applications/Volta.app/Contents/Resources/Driver.kext) to secure location.

And this is the output of running codesign --display --verbose=4 /Applications/Volta.app/Contents/Resources/Driver.kext as suggested in Ricardo Anjos' answer:

Executable=/Applications/Volta.app/Contents/Resources/Driver.kext/Contents/MacOS/Driver
Identifier=com.gmathews.volta.driver
Format=bundle with Mach-O thin (x86_64)
CodeDirectory v=20200 size=345 flags=0x0(none) hashes=3+5 location=embedded
Hash type=sha256 size=32
CandidateCDHash sha1=cbf1caa72d5071c35aa3c020d557a084e6e5a8c9
CandidateCDHash sha256=468cc8b2215b53445cb650c94a76413db62a4815
Hash choices=sha1,sha256
Page size=4096
CDHash=468cc8b2215b53445cb650c94a76413db62a4815
Signature size=4697
Authority=Developer ID Application: Gary Mathews (SFS8238QUB)
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Signed Time=26 Jul 2018 23:14:21
Info.plist entries=19
TeamIdentifier=SFS8238QUB
Sealed Resources version=2 rules=13 files=0
Internal requirements count=1 size=220

Here's also the output for codesign -v on the same file:

/Applications/Volta.app/Contents/Resources/Driver.kext/Contents/MacOS/Driver: valid on disk
/Applications/Volta.app/Contents/Resources/Driver.kext/Contents/MacOS/Driver: satisfies its Designated Requirement

I also followed the same process with the main executable as well as the helper application, and they all checked out (valid signatures, and the same authority and team ID).

I compared the output of codesign to another random third-party kext in my computer, which runs fine without requiring me to circumvent SIP, and I couldn't spot any differences.

Moreover, Volta's FAQ page instructs the user on how to work around SIP, so it seems like a deliberate decision by the developer and not just a mistake.

I'm very bothered by this situation. As the legitimate owner of this machine, and having physical access to it, is there nothing I can do (short of fully disabling SIP) to whitelist this one kernel extension, assuming the developer can't sign the extension for some reason? I don't care if it entails entering cryptic commands in recovery mode, writing stuff to NVRAM or code-signing the extension myself, so long as I don't have to pay Apple $99 for the privilege.

Best Answer

I wrote the developer and received the following reply (I hope he doesn't mind me posting it here):

I would prefer not to have the limitation of disabling SIP to install Volta's kernel driver. But Apple has rejected my request to sign the driver (understandably) as it makes low level changes to the CPU Machine Specific Registers.

You can read about MSRs in Intels architecture documentation (Chapter 35): https://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-vol-3c-part-3-manual.pdf

Why is the kernel driver needed? In order to execute WRMSR and RDMSR instructions kernel level permissions are required.

It is possible to partially disable SIP by only allowing unsigned kernel drivers to be installed, but maintaining other SIP protections.

Unsigned drivers used to be allowed until recent macOS versions; as long as you are careful with what you install on your Mac you should be fine.

I replied asking if Apple also had veto power over kexts even if they were not distributed in the App Store. His reply:

Correct, regardless of distribution method.

https://developer.apple.com/library/archive/documentation/Security/Conceptual/System_Integrity_Protection_Guide/KernelExtensions/KernelExtensions.html

"You can request a Developer ID Certificate for signing kexts by visiting https://developer.apple.com/contact/kext and filling out the required details."

My request was rejected, I even referenced the 'Intel Power Gadget' in my request as it uses similar MSR instructions as Volta.

I don't think Apple likes the idea of users controlling their hardware. Especially when undervolting can cause stability issues.

Therefore, it looks like if you want to install a kext not blessed by Apple, you have no choice but to disable SIP. Looks like Apple, through some convoluted reasoning, thinks I'll be safer if, in order to run code they don't approve of, I also have to open a gaping hole in my computer's security in the process.

Related Question