We plan to only allow our product to run on a specific version of macos x.
We will test and release an update for each os update from Apple.
Doing a diff on the xnu source code makes it easy to spot changes.
The kexts involved in this discussion are not open source.
As for dtrace, PT_DENY_ATTACH sets P_LNOATTACH in the proc, and that effectively prevent dtrace probing our process (grep the xnu codebase for P_LNOATTACH).
I wouldn't rely on this.
Regarding denying task_for_pid, the mac framework (seatbelt/sandbox) already allows for that to be denied: the profiling tools should do proper error handling.
task_for_pid isn't the issue here. You don't need to use it to profile any particular application. Symbolication, maybe, but that's a separate issue.
In general, debugging and profiling tools need to see everything. Trying to hide things from them is just a cause for error, frustration and bugs.
How are you going to debug and profile your own kext and apps if you hide them from all the tools?
If our daemon is suspended, any network or file access will probably block. I'm guessing Instruments suspend all processes, gather stats, writes them to a file, then resume all processes. If so, it will block while trying to save the stats. I guess we could also double-check in the kernel if the daemon is currently suspended and not try to communicate with it in that case.
Time Profiler will not perform any I/O while a process is blocked, for the recording of data. More generally, symbolication might, and that is driven from userspace. It might be possible to change that in future. You should file a bug report.
We have means of white carding critical processes (such as the dynamic_pager / launchd / etc), so they never trigger communication between the kernel and user-space (ie no deadlocks because of pagefaults).
I can't say what processes may be involved in debugging and profiling; it changes over time.