0

This is really a strange situation. My application is an user agent communicates with my driverkit driver, by our design this app(named myAgent.app) activates my driver(named myDriverKit) since myAgent.app starts then communicate with myDriverKit. In our testing I load it manually by a plist, the content is:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>com.myCom.myApp</string>
    <key>ProgramArguments</key>
    <array>
        <string>/Applications/myApp.app/Contents/Helper/myAgent.app/Contents/MacOS/myAgent</string>
    </array>
    <key>RunAtLoad</key>
    <true/>
    <key>KeepAlive</key>                                                         
    <true/>
</dict>
</plist>

All is running perfectly (under SIP off when we are't granted entitlement yet).

Then we package it, myDriverKit looks like running well when it's activated during installing, the post-install script writes in the end:

CONSOLE_USER=$(stat -f%Su /dev/console)
su -l "$CONSOLE_USER" -c '/bin/launchctl load /Library/LaunchAgents/com.myCom.myAgent.plist' 2> /dev/null

However after reboot, the myDriverKit doesn't work anymore! It looks like survive when I using systemextensionctl list to look for it, but check console, hook it by log stream, I can't find it anymore. Unless I manually do systemextensionctl reset and restart myAgent.app to let it able to survive permanently.

I did several test:

  1. Don't auto launchctl load myAgent but manually load it myself when install finished -> it works.
  2. chmod 644 com.myCom.myAgent.plist then re-build package -> fail
  3. Don't allow myDriverKit in Security then allow it after reboot -> works
  4. use /usr/bin/sudo -u $USER /bin/launchctl load -S Aqua /Library/LaunchAgents/com.kensington.trackballworks.plist in post-install script instead->fail

Seems myAgent.app starts by install script is different with starts by myself. What's the possible root cause? Is it possibly in the post script or in myAgent.app activation process? Appreciate if any reply Orz.

Vannes Yang
  • 141
  • 6
  • What macOS version is this? If it's a beta, have you checked the release notes in case this is covered by a known issue? Have you checked if your dext is simply crashing? – pmdj Sep 08 '20 at 17:43
  • We test it on 10.15.6. I'm sure that my dext is not crashed when system reboot. However I got something...My installer originated installs .kext which owns the same function with dext, in our design the kext is `kextunload` and `rm` in postinstall script when OS is 10.15.6 above. If I remove the kext from my .pkg, this situation doesn't occur anymore. – Vannes Yang Sep 09 '20 at 07:27
  • So now I trying to find a method not put kext into /Library/Extension when OS is 10.15.6 above...thus I can avoid this status. Help! I can't sleep well for several weeks! – Vannes Yang Sep 09 '20 at 07:30
  • Put the kext(s) you don't want to install on 10.15.6+ in a sub-.pkg of their own, and only enable that selection in the overall distribution pkg on older versions. But you probably need to update your software to delete any leftover kexts if the OS is subsequently updated by the user. (I.e. user installs your driver on 10.15.5, uses kext; user updates to 10.15.6, now the dext should be used so your software needs to detect this and remove the kext) You can also try changing the probe score – pmdj Sep 09 '20 at 11:48
  • Yes Phil you are right! I'm trying to make my kext into a .pkg as a component of my distribution package...I'm not familiar with the pkgbuild->productbuild process...need more time to build and test...Orz – Vannes Yang Sep 09 '20 at 19:24
  • I prefer let user use the original kext if they installed our product in early version OS then upgrade up to 10.15.6. My detect way is easy...just find if the kext is still in /Library/Extensions/ or not, if yes I keep the old way. If user upgrade their OS to 11, the kext will be disabled automatically. On 11 my app will auto use dext. Hope all under plan! – Vannes Yang Sep 09 '20 at 19:29

1 Answers1

0

I'd answer this question myself. The root cause of such strange situation is user activates(the moment clicking allow button in security) dext when the installer processing kextcache.

If we specify a kext to copy to /Library/Extensions/ in a .pkg, installer will do kextcache automatically during install process. That's why the installer needs so long time to finish installation.

If user activate a dext during kextcache processing, the dext seems working but after reboot the dext will not effect anything even though it shows "Activated enabled" when systemextensionctl list is issued.

This should be a bug in macOS, in my thought.

Vannes Yang
  • 141
  • 6