2

Inside a KEXT, I need to do some processing where I would get either a proc_t or just a pid. If I go the pid route, I would do a sysctl() of sorts.

Unfortunately, I can't do either. proc_t is undefined and sysctl() isn't either. sysctlbyname() can be called but kinfo_proc isn't defined. If I try to use proc_t, the compiler complains about forward definition of [struct proc]

I'm assuming that sysctl() is there to be used in user mode but is there any way I can use proc_t? I tried to use the XNU/osfmk/bsd include dir but then it won't compile because of redefinitions and other errors.

It's a little disconcerting and I'm still trying to wrap my head around what I can and cannot do. Surely this can be done but I just don't quite know how.

E.T
  • 1,095
  • 1
  • 10
  • 19
  • What are you **actually** trying to do? Specifically, what sysctl are you trying to call? Many sysctls have direct kernel API equivalents. `proc_t` is `typedef`'d as `struct proc*` - that struct is indeed opaque, but there are quite a few APIs that let you access various parts of the proc struct indirectly. (`#include `) Basically, it's really not clear what you're asking, and what you are actually trying to achieve. Before trying to answer any more sub-questions, I want to make sure this isn't an XY problem. – pmdj Jul 24 '13 at 18:23
  • When a program is started I want to forward some info back to user mode. The info can be as simple as a PID but I will most likely need more information such as the parent PID, path, and a few other things. Since I couldn't get the information from the proc_t, I figured that I could use a sysctl() but that's obviously wrong. I can send the proc_t* to my kext but it doesn't know (well, I don't) how to extract the information properly. It's probably a little unclear to you because I've started programming on OS X a couple weeks ago and my experience is with the Windows kernel :) – E.T Jul 26 '13 at 15:03

1 Answers1

3

OK, I'm going to try and take a stab at the question I think you're asking.

As you've discovered, a proc_t is a pointer to an opaque struct proc. Don't write it off though, as there are various functions that operate on such pointers, so you don't need to gain direct access to the struct (which helps maintain binary compatibility). Most of these are declared in sys/proc.h in the Kernel.framework - i.e. /System/Library/Frameworks/Kernel.framework/Versions/A/Headers/sys/proc.h. You mention PID and parent PID, for which there are the following:

/* returns the pid of the given process */
extern int proc_pid(proc_t);
/* returns the pid of the parent of a given process */
extern int proc_ppid(proc_t);

There are also functions for going the other way - getting the proc_t for a PID etc.

Note that these functions are part of the BSD portion of the kernel, so your kext needs to declare a dependency on the BSD KPI bundle in its info.plist. (look up the kextlibs tool if you haven't come across this yet)

Coming from Windows, you'll probably have to get used to reading header files and source codes instead of documentation. Much of the OSX kernel API is undocumented.

pmdj
  • 22,018
  • 3
  • 52
  • 103
  • 1
    Thanks! I read the proc.h and I'm using a few of those functions. Thanks for the tip as well. I've gathered as much documentation as I could but sifting through the header files is a very good approach. I still have tons of stuff to learn but so far it's been quite interesting. I have to look at things in a slightly different way too. – E.T Jul 28 '13 at 18:05