# List of known threads



## Maelstorm (Jul 28, 2012)

Is there a way to get a list of threads known to the scheduler?  I know about runqueue(9) and sleepqueue(9), but are there any others?  I'm writing a kernel thread that will get the list of all known threads in the system and bash it against the allproc list to see if there are any hidden processes.  If it finds one, then it puts the associated proc back on the list and prints a message to the console.


----------



## Maelstorm (Jul 29, 2012)

After doing some research, I have found that this cannot be done with the current version of the kernel.  The reason is that there is a internal structure inside /usr/src/sys/kern/sched_ule.c that cannot be accessed from outside, effectively blocking off access from exterior sources.  The way that I see it, there are only two possible solutions to this quandary:


Copy the structure definition into my code so I can use it locally.  The problem with this is if it changes in the future (which is a definite possibility), then the definition in my code must change as well.  There are also other issues to consider as well.  The format of the structure changes depending on various defines in the kernel config file.
Modify /usr/src/sys/kern/sched_ule.c to return a list of PIDs that are in use.  This may be the better option, but on each update to the scheduler, the file will need to be re-patched.  Then if something radically changes, the code will have to go through a re-think to make it work again.  Furthermore, a kernel recompile will be necessary to include the new code.  Not something someone is willing to do just to get a KLM to work.

If anyone has any other options that can be considered, I am listening.


----------



## t1066 (Jul 29, 2012)

Maybe you may look into procstat()?

`$ procstat -t -a`

would show all known threads.


----------



## Maelstorm (Jul 29, 2012)

Interesting tool.  However, it's not what I need.  The information that I am gathering is from a kernel space thread running under proc0, the kernel process.  As such, this is running in kernel mode.  What I am trying to do is collect the PID from the threads that are known to the scheduler and bash those PIDs against the allproc_list and the zombie list.  Any PIDs that the scheduler knows about that are not on the allproc_list or the zombie list is a possible hidden process.  In a system compromise, userland tools such as ps(1) and procstat(1) cannot be trusted since they get their information from the kernel via the kern.proc sysctl(8) which in turn gets the information from the allproc_list and zombie list.

The best way to detect a KLM rootkit is to have a KLM go through the kernel looking for any changes to the data structures.  I have found the source code to a FreeBSD rootkit on the web so I have been using that to test my software detection routines.  The system call scanner thread does work as it posts an alert to the console if changes are made to monitored entries in the syscall table.


----------

