|
|
Honeypots
Semantics of command_id, process_id, process_to_com, process_tree Jun 23 2006 02:11PM troy d. straszheim (troy resophonic com) (1 replies) Re: Semantics of command_id, process_id, process_to_com, process_tree Jun 23 2006 07:16PM Frank S Posluszny, III (fsp mitre org) (2 replies) Re: Semantics of command_id, process_id, process_to_com, process_tree Jun 23 2006 07:45PM Edward G. Balas (ebalas grnoc iu edu) (1 replies) Re: Semantics of command_id, process_id, process_to_com, process_tree Jun 23 2006 08:14PM Frank S Posluszny, III (fsp mitre org) |
|
Privacy Statement |
> > There are also some processes absent from process_to_com entirely,
> > like processes 7 and 12:
>
> Sorry, don't know about that one.
Number *that* low on a Linuxoid kernel is almost certainly a kernel
thread (see kernel/pid.c and the use of RESERVED_PIDS in alloc_pidmap()
for all the gory details, but basically, all PIDs under 300 (by default)
are reserved for kernel threads). It's quite possible that 7 and 12
were threads created during boot to do things like scsi initialization
and so on (on my laptop, PID 8 is kblockd, and 9 is kacpid, then a
big jump to 117 cqueue and 120 khubd (USB support)).
If you're *really* curious to identify it, you'd have to add instrumentation to
kthread_create() in kernel/kthread.c and/or the kernel_thread() function in
arch/<mumble>/kernel/process.c - kernel_thread() calls do_fork() which is
what will end up assigning the PID to the thread.... You probably don't
want to instrument do_fork() itself unless you plan to spam yourself with
printk output for *every* fork() you do.. ;)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Exmh version 2.5 07/13/2001
iD8DBQFEnFIjcC3lWbTT17ARAto2AKCCN6QAjnqKTvfqm2y3Ooy0c6rm3gCgi4QP
4tupS4hO5wZo2xVeCBBaLe4=
=UGTp
-----END PGP SIGNATURE-----
[ reply ]