Duplicate System Extensions appeared after an upgrade to the version number, issue with loading updated extension

Hi Developers,

I've run into an interesting issue when upgrading my system extension powered app. I use system extensions to provide security software to protect users. We recently released a new version of our software and extension. A small subset of users upon upgrade are running into an issue where both the old system extension and new system extension are listed as [active enabled].

Both the old and new extension have identical signing, bundle IDs, and team IDs, with the only difference being a version change.

Our container app logged out an error code 3 and then error code 4 on subsequent launch attempts. 3 means it was trying to launch from a location other than /Applications which doesn't make sense as our app is located in /Applications. 4 means "extension not found"

It's looking pretty clear that something has gone wrong during the upgrade/replacement process but we're not sure what.

We have several questions:

  1. How can we resolve this issue without requiring users to disable SIP and use systemextensionsctl? This is not a customer friendly way of resolving the issue and our customers are not necessarily technical, making this a challenge to support.

  2. What could have possibly gone wrong during our upgrade to result in multiple system extensions with the same teamID and bundleID being installed? Running ps aux does show only one system extension running, so even though systemextensionsctl list shows multiple as active and enabled, only one is running

  3. Is this possibly a bug in Big Sur that needs to be addressed by Apple? At a minimum, it would be great if a user or software developer could uninstall their own system extensions as easily as they can install...


Thanks,

Trace
Up vote post of DeveloperTrace Down vote post of DeveloperTrace
1.4k views
Posted by
DeveloperTrace
Reply
Add a Comment

Replies

Hi Trace,

I have encountered the same issue before on macOS 11.0.1, which I had previously raised with Apple: FB8963999.

I suspect this is a bug, because on the affected systems, I was seeing crash reports for sysextd with the message:

Fatal error: Activate found 2 extensions in active state, ID: <bundleid>, teamID("<teamid>"): file sysextd/extension_manager.swift, line 1371

Our product is shipped as an installer package. To work around the issue, the install script for the package was updated to deactivate the current System Extension before installing the updated Application containing the new System Extension.

Not great, but does seem to stop the issue from happing and is much better solution than telling affected customers to disable SIP and use systemextensionsctl uninstall.

Hope that is of some help,
Omar

Posted by
OmarIkram
Post not yet marked as solved Up vote reply of OmarIkram Down vote reply of OmarIkram

  • Hello Omar, I am in the same boat. Our application comes with installer and I am looking for a way to deactivate the current running system extension via installer script. Can you point me to relevant documents and/or snippet on how you are able to achieve this via the script. Thank you.

    —
    vtewari
Add a Comment
Hi Omar,

I appreciate your reply. One of the biggest obstacles facing us is that we do background updates which makes that solution less than ideal as it appears to prompt for a password to deactivate, but we definitely appreciate your insights and the feedback ID from your submission as well! Hopefully Apple can find the fix for this issue quickly.

Trace
Posted by
DeveloperTrace
Up vote reply of DeveloperTrace Down vote reply of DeveloperTrace
Add a Comment
Hi Trace,

You're seeing the password prompt, because the deactivation request is triggering an authorization right "com.apple.system-extensions.admin", which has to be authorized using Authorization Services, even when running as root. However, there is a workaround for this too.

You can grant root access to the right by running the command:

security authorizationdb write com.apple.system-extensions.admin is-root

That way, your background update process (assuming it is running as root) can deactivate the System Extension without a password prompt appearing.

I strongly recommend that you backup the right first, before making any modifications, and restore it back to it's original state when done.

Again, not that great, but does work.

Omar

Posted by
OmarIkram
Up vote reply of OmarIkram Down vote reply of OmarIkram
Add a Comment