Re: [Qemu-devel] How to get guestOS's information

["andrzej zaborowski" <balrog@zabor.org>]

On 26/10/06, andrzej zaborowski <balrog@zabor.org> wrote:
> Hi,
>
> On 26/10/06, KazuyaMatsunaga <sd03075@toyota-ti.ac.jp> wrote:
> > Hello,
> >
> > It is impolite to write an unexpected letter. I am a college student in
> > Japan. I belong to information processing system laboratory, and I work on
> > intrusion detection system. We are developing intrusion detection system
> > using system calls. Now, it operates only on Linux. I would like to operate
> > it in more platforms. I think it is possible to found guest OS's
> > abnormality by observing it from the hostOS. I would be extremely happy if
> > it could be operated on the Qemu. Do you think that it is possible? Now, my
> > system uses only processID and frequency of system calls. In a word, I would
> > like to know how to get gestOS's information (processID and frequency of
> > system calls).
>
> This is a bit difficult because these things are not standarised in
> any way across architectures and across operating systems. If you know
> that your guest OS is Linux, though, you can quite easily extract this
> information if you have the kernel's sources (but still not in an
> architecture independent way), without modifying the kernel or qemu.
> For example I recently found that on ARM the list of processes and any
> associated information can be obtained in gdb with:
>
> (gdb) print ((struct task_struct *) (((void *) ((struct thread_info *)
> ($sp & ~8191))->task->tasks->next) - 0x6c))->comm
> then
> (gdb) print ((struct task_struct *) (((void *) ((struct thread_info *)
> ($sp & ~8191))->task->tasks->next->next) - 0x6c))->comm
>
> and so on iterating until you hit the same process again, provided
> that the kernel's symbol table is loaded. The number 6c is the offset
> of the field "tasks" inside the struct task_struct which is defined in
> include/linux/sched.h which [the offset] is architecture dependent,
> and the ($sp & ~8191) part is the text of the current_thread_info()
> function, defined in include/asm-arm/thread_info.h and is also arch
> dependent but should be something similar on i386. The advantage that

Yep. Now that I checked, exactly the same except you probably have to
replace "sp" with "esp" and if you're using 4K stacks then it's 4095
instead of 8191.

> using gdb has over "ps" is that it works even before the kernel starts
> userspace and even after a kernel crash. Now to intercept syscalls
> it's enough to set breakpoints in the right places. This can be done
> using gdb or you can make a very simple program that talks to qemu
> over the gdb protocol.
>
> If you're willing to modify qemu, several architectures have a special
> instruction used for syscalls, like "swi" on arm and "int" on i386,
> which you can easily trap, but it's not obligatory for an OS to use
> this instruction.
>
> As Rob said the only *correct*, and the easiest way is to modify the
> guest kernel.
>
> hth,
> Andrzej
>


-- 
balrog 2oo6