Open Radar

 
Please provide a descriptive title for your feedback:
System Extension database can get into a state where extension can't be installed successfully
Which area are you seeing an issue with?
DriverKit
What type of issue are you reporting?
Incorrect/Unexpected Behavior
Description
Please describe the issue and what steps we can take to reproduce it:
While testing under-development driver extensions (dexts), my test macOS systems have many times got themselves into such a bad state that installing the dext can no longer be done successfully until the /Library/SystemExtensions/db.plist is manually cleaned up and the leftover extensions are manually deleted from /Library/SystemExtensions/*/

This essentially does not seem to happen if the following testing flow is used:
1. Copy app hosting dext to /Applications
2. Run app, trigger dext activation request
3. Authorise dext via System Preferences Security & Privacy pane
4. Test the dext (plug/unplug device[s], connect user clients, restart app, etc.)
5. Trigger dext deactivation request
6. Immediately reboot the system

However, if I miss off step 5 and/or step 6 and attempt to install a new version of the dext for testing before the old one has been eradicated from the system, especially if a dext process has crashed, the system will often end up in a state where it apparently confuses itself. In this state:

1. One or more copies of the dext are in /Library/SystemExtension/<UUID> directories, and appear in the db.plist in the state “terminated_waiting_to_uninstall_on_reboot”
2. Rebooting may clear some of these but not all.
3. Starting the dext wrapper app and initiating the activation request APPEARS to work (and the delegate completion method gets called with a success code)
4. The dext does not actually start up, although a corresponding IOUserService may appear in the I/O Registry (no dext process runs, however)
5. kextd logs ‘kextd: (IOKit) [com.apple.kext:kextlog] Error encountered during approval check: Error Domain=OSSystemExtensionErrorDomain Code=2 "(null)”’, ‘Driver Extension is not approved to run:’, ‘<bundle ID> failed security checks; failing.’, and ‘(IOKit) [com.apple.kext:kextlog] String/URL conversion failure.’
6. Requesting deactivation will appear to succeed once, and one of the detritus dexts will usually be cleared on reboot, but the system remains stuck and has gained a new detritus dext.

I have included:
bad-library-systemextensions.zip - the contents of /Library/SystemExtensions when such a stuck state has been reached
dext-approval-system-log.rtf - a system log excerpt from immediately after clicking “Allow” in the Security & Privacy pane after requesting install of the dext embedded in the DemoDriver app from this stuck state. The delegate method reports success, and an object appears in the I/O Registry, but the dext’s code never runs.
bad-library-systemextensions-after.zip - the contents of /Library/SystemExtensions afterward
DemoDriver.zip - binary of the app with embedded dext
DemoDriver-source-bad-library.zip - source & Xcode project for DemoDriver.

I am hitting this on a regular basis (whenever I happen to forget either the uninstall or reboot steps) while testing on macOS 10.15.4 and 10.15.5 beta (19F72f). Note that SIP is disabled and amfi_get_out_of_my_way=0x1 on these Macs to allow development signing of dexts and user clients.
File Uploads
System_Profile_full.spx
sysdiagnose_2020.05.06_21-21-28+0200_Mac-OS-X_Macmini6-2_19F72f.tar.gz
dext-approval-system-log.rtf
DemoDriver.zip
DemoDriver-source-bad-library.zip
bad-library-systemextensions.zip
bad-library-systemextensions-after.zip