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.

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);

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

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.

I believe you are running into this problem, you need to define keyNSEndpointSecurityMachServiceName/key string$(PRODUCT_BUNDLE_IDENTIFIER)/string in your info.plist. It's been a while since I fought this, but I think that right now it's publishing your XPC endpoint as TeamID.bundle ID.text.xpc I'm sure that Quinn or others will correct me if I'm wrong.

I see the same error from systemextensionsctl afterwards too. I filed a FB ticket for that, FB9163360. Keep updating it after each beta when it happens again. I think in beta 1 and 2 (maybe just 1?) that it literally crashed after logging that. That's when I created the ticket.

This is the same approach I used to use for debugging KEXTs, and for the same reason: Interactive debugging of low-level system components is, at best, deeply unpleasant and, in the worst case, completely infeasible. Deeply unpleasant. Quinn, you are a master of understatement :)

Monterey beta 6 is behaving like Big Sur and is working. All is good in (my) the world. Thank you again, Quinn, for letting us know to test it again.

This link says that it's OK now, yesterday there was a problem https://developer.apple.com/system-status/

Couldn't you just run systemextensionsctl list | grep <your extension name> in an NSTask and parse the output, if any?

You will need to use an MDM system that has a profile automatically allowing the system extension.

The first thing I'd check is to see if the local drive is mounted with noatime set, and the pen drive doesn't have it set. It might have nothing to do with your system extension.

Mine is working fine on an M1 Mini. I did have to turn Full Disk Access back on after the last install after updating, but other than that, it's working as expected. I know that doesn't help you a lot, but it doesn't seem to be a regression.

Well, if you have a kernel driver or ES system extension, you could watch for someone reading your plist and deny it.

I had the same question almost 3 years ago. I was relying on the PID to determine which process started when. But I got this response that cleared this up. I validated this by logging a message at startup in my Endpoint Security extension and in our launchd process. Even though the launchd process had a much lower PID, the system extension logged its message first. HTH Here is the response from DTS: Engineering has provided the following information regarding this issue: We believe this is a misunderstanding of how PIDs get assigned to new processes - this happens at fork(2) time, not execve(2)/posix_spawn(2) time. The early boot mechanism holds up new images from completing the exec, but the original process (e.g. commonly launchd/loginwindow at startup) has already forked a new process. A lower PID number does not mean that a new image has begun executing. The interesting test case to perform here is to execute non-platform code as early as possible during system startup, before your ES client makes its first subscription. What you should see is that process being held up until either the ES client subscribes to some set of events, or the early boot timeout is reached and EndpointSecurity begins allowing non-platform binaries to continue executing. (tip: this is more easily done by running some non-platform command line binary from Terminal.app rather than launching some non-platform GUI app.) This was retested on 10.15.4 and 10.15.5. No issues were encountered and non-platform execs were successfully held until all early boot clients connected and made their first subscriptions (or timeout was reached).