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

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

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
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