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. If so, I have some questions: - What is the original reason to map/unmap VM at start and end of kvm_run()? - I did look at the code, but dont see where does what you said. Any hint? Thanks, Jun > > > > > >Any idea? > > > >Thanks, > >Jun > > > > > >On 6/25/07, Dong, Eddie <[EMAIL PROTECTED]> wrote: > >> Jun Koi wrote: > >> > On 6/25/07, Dor Laor <[EMAIL PROTECTED]> wrote: > >> >>> On 6/25/07, Dong, Eddie <[EMAIL PROTECTED]> wrote: > >> >>>> [EMAIL PROTECTED] wrote: > >> >>>>> On 6/25/07, Dor Laor <[EMAIL PROTECTED]> wrote: > >> >>>>>>> I am wondering how KVM handles debug and breakpoint > interrupt? > >> >>>>>>> Does it process them like normal NMI interrupt, or is there > any > >> >>>>>>> special processing? > >> >>>>>>> > >> >>>>>> > >> >>>>>> I haven't use it but KVM does support qemu'd gdbstub. Both > single > >> >>>>>> step and breakpoint are possible. From the source code (vmx.c) > it > >> >>>>>> seems like handle_exception function handle them as regular > >> >>>>>> exceptions (non nmi). > >> >>>>> > >> >>>>> Are you sure? the kvm_vmx_exit_handlers function pointer arrays > >> >>>>> has the index named EXIT_REASON_EXCEPTION_NMI, so it must be > >> >>>>> handled as NMI to me. > >> >>>> > >> >>>> This exit reason is either NMI, or software interrupt or > exception. > >> >>>> > >> >>>> Refer update_exception_bitmap for the setting of VM Exit for > which > >> >>>> exception (int n). > >> >>>> > >> >>>> In normal situation, I think guest int 1/3 directly get handled > in > >> >>>> guest. > >> >>> > >> >>> > >> >>> So you mean interrupts 1/3 do not cause VMExit?? > >> >> > >> >> Int 1 is updated in the update_exception_bitmap, so it does causes > >> >> vmexit. > >> >> > >> > > >> > Is there any reason only int 1 causes VMExit, but not int 3? > >> > > >> This int 1 exit is for host debugging guest purpose not guest self > >> debuging. > >> For the case host debuging guest purpose, DR register is used, so no > >> need of INT3, > >> but INT1 can be used as single step and probably used to by pass the > DR > >> breakpoint. > >> > >> For guest self debug purpose, no INT 1/3 trap. So seemlessly > supported. > >> Eddie > >> > ------------------------------------------------------------------------- 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
