[Qemu-devel] How to get guestOS's information
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 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] How to get guestOS's information
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 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] How to get guestOS's information
Hi, On 26/10/06, KazuyaMatsunaga [EMAIL PROTECTED] 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 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] How to get guestOS's information
On 26/10/06, andrzej zaborowski [EMAIL PROTECTED] wrote: Hi, On 26/10/06, KazuyaMatsunaga [EMAIL PROTECTED] 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 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] How to get guestOS's information
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. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] How to get guestOS's information
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 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
