>On 6/27/07, Dor Laor <[EMAIL PROTECTED]> wrote: >> >BTW, I think that turning on debugger from qemu is a dangerous action, >> >from security point of view. Once the gdbserver is started, anybody >> >can connect to it (with gdb) and modify VM memory in anyway he wants >> >(like overwrite kernel with malicious code). The problem why this is >> >feasible is because there is no authentication machanism on gdbserver >> >at all. >> >> How can gdb-ing qemu harm the kernel? Although the whole guest memory >> image is mapped to qemu and writable for gdb, kernel data structures are >> not mapped (except for kvm_run and it has validity checks). So I don't >> think it's a security hole. > >You mean kvm_run() maps guest VM at the start, and unmaps it at the >end? That is interesting! That is obviously more secure, as when >debugger is active, it cannot modify VM.
It's not why I meant. Kvm_run is mapped only once after the creation of the vcpu (in kvmctl.c). The guest has ability to change at anytime the content of the kvm_run structure but it has no pointers and the values are checked against validity check each time the kernel uses it. So except for ruining the guest context gdb or malicious user cannot harm the kernel or other guests. Other than kvm_run only the guest virtual memory is mapped by user space and again one can harm only itself. HTH, Dor. ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
