The launchd launches LaunchDaemons and the system extensions after the LaunchAgents when FileVault is enabled

But I expect that they will launch before LaunchAgents and other user services.

That’s not a valid expectation in general. macOS uses a launch on demand system and the ‘root’ of much of this demand is the loginwindow session starting and bringing in a bunch of launchd agents.

However…

the flag NSEndpointSecurityEarlyBoot should guarantee an earlier start than other services.

Indeed.

Are you building an Endpoint Security product? Or was this just a diagnostic test?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

I'm building an Endpoint Security product. We use Endpoint Security as a LaunchDaemon in our product. But, after I found this behavior, I tested it as a system extension. I'm searching for a way how to launch Endpoint Security earlier than LaunchAgents on systems with FileVault. Maybe there are other ways to guarantee it?

Maybe there are other ways to guarantee it?

There is not.

The canonical solution to this is NSEndpointSecurityEarlyBoot. If you’re seeing cases where that doesn’t work, that’s definitely bugworthy.

Please post your bug number, just for the record.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

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

Thank you for sharing this information.

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.

I created the bug https://feedbackassistant.apple.com/feedback/12001338. When I was preparing the test data for the description, I got the same behavior. System extension could get the agent process identifier, but the agent logged only after subscription. But I thought that it was incorrect. I still think so.

I'm searching for a way how to launch Endpoint Security earlier than LaunchAgents loaded by launchd. I want to block the agent before the launchd sets up any resources for it, e.g. sockets or paths to listen, mach services names, etc.