third-party kernel extensions

[3460169]

Please forgive me if this was discussed elsewhere and my search-fu skills are failing today. It's Friday and the week has been exhausting -- in part because of Monterey headaches.


I use a SteelSeries mouse and their "Engine" software still requires a kext (kernel extension). Back in Big Sur (which I personally skipped and stuck with Catalina until Monterey) Apple implemented some restrictions around third-party kernel extensions. If third-party extensions are enabled, they can't be loaded on-demand. From the article: Instead, they’re merged into an Auxiliary Kernel Collection (AuxKC), which is loaded during the boot process. That's all well and good but it goes on to talk about how user-consent is needed to load such extensions. This particular extension, during the install process on Monterey, was basically flatly rejected by the OS with a dialog message box stating to the effect that the developer needs to update their code or some such. Hmmm great -- and yeah I've emailed Steelseries as well, since it seems they have been sitting on their 🍑 and haven't updated this Engine software for Big Sur either.


Anyway bottom line is I'm wondering if there's a way to get user-approval for this kext (edit: seems there is... see below!) and get it loaded so that the supporting user-space software for it is usable. This system has a clean installation of Monterey, set up as "new", on an Intel Mac. I just installed the Steelseries Engine software last night (v14.0.0) and during that installation there was never an opportunity to approve or deny the kext; seems macOS just flatly denied it. System Information -> Software -> Disabled Software claims "No User Consent", which is true, but there was no opportunity to give consent haha.

The knowledge article linked talks about the spctl command-line tool briefly in the context that third-party kexts Are allowed to load without user consent by using the spctl command-line tool available when a Mac was booted from recoveryOS, however the details around how to do this are sparse.

edit: hmmm... a little bit more of Google-fu and I see this article over at MIT about using spctl for approval of kexts. In recovery mode: /usr/sbin/spctl kext-consent add TEAMID

TEAMID I think is some sort of vendorID. A little more Google-fu leads to this post about VMware kext stuff:

System extension | Apple Developer Forums

developer.apple.com

and in turn a google doc with a list of many TeamIDs (including that of Steelseries).

Gonna give this a shot and see what happens. Hopefully not some kernel panic loop lol. That'll be fun.
This intent here is to:

1. Reboot in recovery mode (this is required to make changes with spctl)
2. Execute the appropriate spctl command to allow Steelseries kext to load.
3. Reboot and see how she do.

 

[3460169]

This is really beyond frustrating. I was able to get the kext loaded, which is good:

It's not necessary to disable SIP. It's necessary to add the "team ID" of the kext to the kext-consent list, and then use kmutil with the "trigger-panic-medic" option to essentially reset the third-party kexts so they can be re-approved by the user the next time they are loaded.

However the userland application, their "Engine" software, doesn't see the hardware. I have two different SS mice and neither are recognized by the software. I imagine it's some esoteric permissions issue in the bowels of Monterey.

And yes, the mice can be used with general/basic configuration via the generic mouse UI in System Preference, but nothing else mouse/brand specific can be configured (macros, button mapping, etc).

On the plus side I learned a few things about draconian kernel extension management today, and I spent a couple hours of an otherwise slow work-day doing non-work things.

 

[3460169]

BTW how you find the "Team ID" involves the codesign CLI utility.