1 Reply
      Latest reply on Mar 24, 2020 1:19 PM by joconnor
      brantatsilabs Level 1 Level 1 (0 points)

        Hi. I have a customer who is unable to load a KEXT under MacOS 10.15.3 that they were previously able to load under 10.15.1.

         

        I asked them to try to load it from the command line using kextutil. This is the error they received:

         

        MacBook-Pro:Extensions user$ sudo kextutil SiLabsUSBDriver.kext
        Password:
        Kext rejected due to system policy: 
        { URL = "file:///Library/StagedExtensions/Library/Extensions/SiLabsUSBDriver.kext/", ID = "com.silabs.driver.CP210xVCPDriver" }
        Kext rejected due to system policy: 
        { URL = "file:///Library/StagedExtensions/Library/Extensions/SiLabsUSBDriver.kext/", ID = "com.silabs.driver.CP210xVCPDriver" }
        Diagnostics for /Library/Extensions/SiLabsUSBDriver.kext:
        MacBook-Pro:Extensions user$

         

        The installer for this KEXT calls KextManagerLoadKextWithURL() and is getting a return code of kOSKextReturnSystemPolicy. I usually take this return code to mean that the user needs to approve the kernel extension in the Security & Privacy pane of the System Preferenes. However, in this case they do not see a message about this kext in that preference pane.

         

        I tried formatting the drive on a test system in my office and reinstalling MacOS 10.15.3 and I was able to install the kext and everything worked the way I expected. The installer called KextManagerLoadKextWithURL() and got kOSKextReturnSystemPolicy and when I opened the Security & Privacy control panel, I saw the "Allow" button for this kernel extension and I clicked it and it loaded properly. But this cutomer has tried the same steps and those steps are all working the same except the Allow button does not appear.

         

        The only difference I am aware of is that their systems are set to Japanese. Their GateKeeper settings are the same ("App Store & Identified Developers") and they are using an admin account for the installation. Of course, you could not authorize the privileged helper tool that the installer uses to install the kext if you did not have an admin account.

         

        When I create the .dmg that this is distributed on, I sign and notarize the .dmg and staple it afterwards and this all is successful. I do not currently notarize the kext itself nor the installer application - I merely sign these.

         

        Would it be worthwhile to try separately notarizing the KEXT? Could this be the reason why it is not loading or showing the "Allow" button when they run kextutil on the command line?