I have for a long time run as sip -without dtrace to use dtrace and this is fine but a few apps I want to read data from seen to run in kernel mode (Little Snitch has several components for instance). Whichever way I try I get either a compile or run time error when trying tracemem(arg0), for instance, in a probe such as

syscall::open:entry /app_is_Kmode/
run time invalid address (0x7fff5fbfdc30) in action #4

PRESENTLY: I detect apps that are in kernel mode OK since trace(ucaller) fails and I catch the error and note such apps. I can then use a probe that attempts to work in kernel mode with those apps e.g. not using copyin() but tracemem(). It seems that either memory protection or the dtrace implementation is blocking my attempts. I think that stack() will show 2 frames in kernel symbol space... so there is some limited access.

But what causes my problem, and is there anything I can do?

A particular possibility might be to SIP -without debug protection. But that would be quite a major disruption to just try as I have large ramdisk setup over the last few months since last boot with ACL, privs etc that would be hard to rebuild. I have been unable to find any docs on what exactly that area of SIP is doing. (Maybe it should be a different question purely about SIP but obviously I am interested in the context of my problem.)

  • OK, this seems to be a tough one... I have tried to contact a few of the dtrace developers but they have moved on and probably have other pressures. Any ideas about ways to investigate the block and possible ways forward? ( e.g. dtrace source code? dev or app setup of the processes that produce my problem, find out about the sip without debug? Ask apple devs [what route might work as that seems like chaff in the wind!]... other ideas??)... – colin Oct 27 '18 at 11:02

You must log in to answer this question.

Browse other questions tagged .