XPC listener initialized in System Extesnion invalidates incoming connection under certain conditions

Question

Created Apr ’23

Replies 3

Boosts 0

Participants 2

I found a problem where a process tries to connect to System Extension and connection is invalidated. XPC listener has to be disposed and initialized again. This happens when System Extension executes tasks in following order:

NSXPCListener initialized
NSXPCListener.resume()
NSProvider.startSystemExtensionMode()

Result: Connection is invalidated and not only that the client has to retry connection, nut also System Extension must reinitialize listener (execute step 1 and 2).

However if I call

NSProvider.startSystemExtensionMode()
NSXPCListener initialized
NSXPCListener.resume()

It works as expected and even if the connection is invalidated/interrupted, client process can always reconnect and no other action is necessary in System Extension (no need to reinitialize XPC listener),

In Apple docs about NSProvider.startSystemExtensionMode() it says that this method starts handling request, but in another online article written by Scott Knight I found that startSystemExtensionMode() also starts listener server. Is that right? PLease could you add this info into the docs if it is so? https://knight.sc/reverse%20engineering/2019/08/24/system-extension-internals.html

I would like to use following logic:

Call NSProvider.startSystemExtensionMode() only under certain circumstances - I have received some configuration that I need to process and do some setup. If I don't receive it, there is no reason to call startSystemExtensionMode() yet, I don't need to handle handleNewFlow() yet.
Connect XPC client to System Extension under certain conditions. Ideally communicate with client even though System Extension is not handling network requests yet, that is without receiving handleNewFlow().

Basically I consider XPC and System Extension handling network requests as separate things. Is that correct, are they separate and independent? Does XPC communication really depend on calling startSystemExtensionMode()?

Another potential issue: Is it possible that XPC listener fails to validate connection when client tries to connect before System Extension manages to complete init and park the main thread in CFRunLoop?

Note: These querstions arose mostly from handling upgrades of System Extension (extension is already running, network filter is created and is connected and new version of the app upgrades System Exension).

Thanks.

Boost

Answer 1

Robert_Developer OP

Apr ’23

BTW does NSProvider.startSystemExtensionMode() need to be started from the main thread? Can it be started from a background thread that doesn't event use CFRunLoop, but a unix loop based on epoll?

Does NSXPCListener has to be started from main thread?

0

Answer 2

Robert_Developer OP

Apr ’23

Additional Info: The issue occurs only on ARM (Ventura and Monterey) not on Intel.

XPC simply doesn't work after upgrading system extension on ARM. I tried to kill sysextd, nesessionmanager and other processes. Basically I'm trying to kill a process that manages XPC connections and info about processes and their signature validation (maybe it's somewhere deep in kernel and it's not possible to resolve it by this hack). It is possible that when trying to connect to XPC while starting our services in posinstall scirpt, installd hasn't quite yet completed and perhaps OS considers bundle signature not valid yet.

Workaround is rebooting the machine, but we try to avoid that as much as possible. After reboot XPC works fine with upgraded system extension.

0

Answer 3

Systems Engineer OP

Apple

Apr ’23

It looks like there are a few questions throughout these posts but I wanted to cover the how the System Extension machinery works here and hopefully that will shed some light on the other questions.

When the system start a Network System Extension the main function is called as the entry point for this process starting and then, as the documentation says, startSystemExtensionMode creates the functionality so that your container app can communicate with the Network System Extension. This is run on the main queue of the process using GCD and I would leave that as is (I would not add a runloop here). I would also make sure that that any calls to startSystemExtensionMode are left where they are in code as this could affect the communication with your container app if this is method is called again on the NEProvider.
After your Network System Extension is start and is running as it should be, if you need additional communication via XPC with another daemon, then as you have noted, that should work fine. But I would not setup this functionality until after your Network System Extension is up and running smoothly.

0