kappe_m, I had the same question back in the summer and got this work-around from an Apple rep: There is a workaround before the fix is implemented: To implement device access control for mass-storage devices based on e.g. USB serial numbers, ES clients can, before responding to mount events, query the IOKit registry for the service object corresponding to the disk device that is about to be mounted (IOBSDNameMatching). From there they can walk the registry tree to find the responsible USB device and query its properties (IORegistryEntryGetParentEntry, IORegistryEntryCreateCFProperties, IORegistryEntryGetChildIterator etc). Based on that information, they can make a policy decision and allow or deny the ES mount event. This is for USB mass storage events, not any USB device connection. Using the suggestions offered, I was able to get some proof-of-concept code working. Hope this helps.

The formatting got all messed up, best to just look at the header file in Xcode 12.2 beta 2 where I got this

From the header file /**Retains an esmessaget, returning a non-const pointer to the given esmessaget for compatibility with * existing code.* @warning It is invalid to attempt to write to the returned esmessaget, despite being non-const, and * doing so will result in a crash.* @deprecated Use esretainmessage to retain a message. *@param msg The message to be retained * @return non-const pointer to the retained esmessaget.* @brief The caller must release the memory with es_free_message/OSEXPORT APIDEPRECATED("Use esretainmessage to retain a message.", macos(10.15, 11.0)) APIUNAVAILABLE(ios, tvos, watchos) esmessaget * Nullable escopymessage(const esmessaget * _Nonnull msg);

It's the way that the process are launched that is confusing. Here is the explanation from Apple PIDs are assigned at fork time, not exec time. When the ES kext knows there are early boot clients, it holds up the kernel thread performing the execve. So all binaries that would get exec'd (e.g. via Loginwindow, launchd loads, etc.), will all get a new pid - they just won't have code execute if they're non-platform binaries until the ES client connects and makes its first set of subscriptions (and, if they subscribed to AUTH EXEC, the client has the opportunity to DENY the exec from continuing). None of this has anything to do with lower numbered PIDs. I did prove that this was the case by looking at log lines from my extension and my launchd process. The extension logged first, even though its PID was larger.