Debugging Endpoint Security Client daemon

Question

dionita OP

Created Jul ’21

Replies 2

Boosts 0

Views 1.7k

Participants 3

Hello,

We have an endpoint security daemon which also uses some system extensions (network content filtering, file notifications). When building on debug with the correct entitlements (get-task-allow) we cannot attach with the debugger. More precisely, after attach, instead of displaying thread information, the daemon just stops (in logs appears a SIGKILL with no source). Before this happens, the system freezes for about 15-20 seconds, so I'm guessing it's some kind of watchdog that kills the app before the debugger can completely attach. The same happens with a custom built GDB, as well as various versions of LLDB.

How can we find out what kills the daemon and maybe increase the timeout or some other solution like that?

Boost

Answer 1

DTS Engineer OP

Apple

Aug ’21

maybe increase the timeout

You will not be able to debug an ES client interactively. Raising the timeout won’t help because the system is effectively deadlocked by your attempt to attach, and a longer timeout just means that it’ll stay deadlocked for longer.

Some of our debugging tools support a -forkCorpse option that allows them to work against an ES client. See this post for more. AFAIK this is not true for LLDB.

How you proceed here kinda depends on your goals:

If you want to debug interactively, using LLDB to step through your ES client code, that’s simply not feasible.
If you want to examine the state of your ES client after a problem has cropped up, you have a number of options in that space. Let me know if you’d like to pursue those.

I generally avoid trying to interactively debug this sort of code in place. Rather:

I add logging to track the interactions between my code and the OS.
If I need to interactively debug my code, I put it into a test harness (built using the understanding that I gained from my logging) and debug that.

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.

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

0

Answer 2

mdolan OP

Aug ’21

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

0