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

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

[KazuyaMatsunaga]

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



Any help would be greatly appreciated.



Regards,

kazuya

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

[Rob Landley]

On Thursday 26 October 2006 3:23 am, KazuyaMatsunaga wrote:
> Hello,
> 
> It is impolite to write an unexpected letter.

Compared to the mountains of spam I get every day?  Not really. :)

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

If your guest os is using sysenter you could hook that and see how often it's 
getting called.  Or perhaps intercept interrupt 80.

That's about the end of my useful suggestions, though.  Unfortunately 
ProcessID is an abstraction that QEMU doesn't know anything about (it's 
translating machine language instructions and emulating hardware; what it's 
_doing_ is another matter).  Trying to get QEMU to do it is a bit like trying 
to add hardware to your system to determine which user accounts are accessing 
your hard drive.  Your PCI bus doesn't know what a user account is: it's at 
the wrong level and that information just isn't present there.

You'd have to modify the OS you're running to collect that info, unless you 
can figure out execatly where in memory it's stored and add some kind of 
trace to monitor that memory location.  (And that location could easily 
change each time you reboot the system.)

I'm guessing you modified Linux to collect this information.  To get Windows 
or Solaris to do it, you'd have to modify those OSes too.

Rob
-- 
"Perfection is reached, not when there is no longer anything to add, but
when there is no longer anything to take away." - Antoine de Saint-Exupery

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

[andrzej zaborowski]

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

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

[andrzej zaborowski]

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

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

[maestro]

Am Donnerstag, den 26.10.2006, 16:23 +0900 schrieb KazuyaMatsunaga:
> 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).
> 
> 
> 
> Any help would be greatly appreciated.
> 
> 
> 
> Regards,
> 
> kazuya
hello kazuya!

some people here commented on the system call problems. i'd like to say
some words about processIDs:
You might want to consider useing the Page Directory Base Register (PDBR
aka cr3 or in qemu-x86 env->cr[3]) to idenify differnet processes. afaik
it is then OS-dependant how to get the corresponding PID. I did this for
windows and i assume it's a lot easier to do the same for linux/*BSD (as
the source is available). Since you probably will need to check for the
current process quite often, the shorter access times for this
information might come in handy.

cheers
m.

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

[Jamie Lokier]

maestro wrote:
> You might want to consider useing the Page Directory Base Register (PDBR
> aka cr3 or in qemu-x86 env->cr[3]) to idenify differnet processes. afaik
> it is then OS-dependant how to get the corresponding PID. I did this for
> windows and i assume it's a lot easier to do the same for linux/*BSD (as
> the source is available). Since you probably will need to check for the
> current process quite often, the shorter access times for this
> information might come in handy.

Good idea.

However, on Linux cr3 is not updated for every process.  Specifically,
it is not updated for kernel threads which don't have any user-space
mappings of their own.  This is to avoid unnecessary TLB flushes.

-- Jamie