From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Gd9cu-0001Gg-Rk for qemu-devel@nongnu.org; Thu, 26 Oct 2006 14:06:48 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Gd9ct-0001Fj-Oz for qemu-devel@nongnu.org; Thu, 26 Oct 2006 14:06:48 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Gd9ct-0001FI-Ef for qemu-devel@nongnu.org; Thu, 26 Oct 2006 14:06:47 -0400 Received: from [66.249.82.228] (helo=wx-out-0506.google.com) by monty-python.gnu.org with esmtp (Exim 4.52) id 1Gd9cs-0007UB-Os for qemu-devel@nongnu.org; Thu, 26 Oct 2006 14:06:46 -0400 Received: by wx-out-0506.google.com with SMTP id r21so693011wxc for ; Thu, 26 Oct 2006 11:06:45 -0700 (PDT) Message-ID: Date: Thu, 26 Oct 2006 20:06:45 +0200 From: "andrzej zaborowski" Sender: balrogg@gmail.com Subject: Re: [Qemu-devel] How to get guestOS's information In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <001501c6f8cf$b2659bc0$37cb1585@s5pc49> Reply-To: balrogg@gmail.com, qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On 26/10/06, andrzej zaborowski wrote: > Hi, > > On 26/10/06, KazuyaMatsunaga 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