debug and breakpoint interrupts handling?

debug and breakpoint interrupts handling?

[Jun Koi]

Hi,

I am wondering how KVM handles debug and breakpoint interrupt? Does it
process them like normal NMI interrupt, or is there any special
processing?


Thanks,
Jun

-------------------------------------------------------------------------
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/

Re: debug and breakpoint interrupts handling?

[Dong, Eddie]

kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org wrote:
> Hi,
> 
> I am wondering how KVM handles debug and breakpoint interrupt? Does it
> process them like normal NMI interrupt, or is there any special
> processing? 
> 
Do u mean int 1/3 handling? Or DR virtualization?

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/

Re: debug and breakpoint interrupts handling?

[Jun Koi]

Hi Dong,

On 6/25/07, Dong, Eddie <eddie.dong-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> wrote:
> kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org wrote:
> > Hi,
> >
> > I am wondering how KVM handles debug and breakpoint interrupt? Does it
> > process them like normal NMI interrupt, or is there any special
> > processing?
> >
> Do u mean int 1/3 handling? Or DR virtualization?
>

Yes, that is 1/3 interrupts.

Thank you,
Jun

-------------------------------------------------------------------------
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/

Re: debug and breakpoint interrupts handling?

[Dor Laor]

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

The breakpoint set path starts from gdbsutb.c-> exec.c:
cpu_breakpoint_insert -> Qemu-kvm.c: kvm_update_debugger
Call an ioctl from Kvmctl.c:kvm_guest_debug that runs
Vmx.c:set_guest_debug 

HTH, Good luck,
	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/

Re: debug and breakpoint interrupts handling?

[Jun Koi]

On 6/25/07, Dor Laor <dor.laor-atKUWr5tajBWk0Htik3J/w@public.gmane.org> 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.

>
> The breakpoint set path starts from gdbsutb.c-> exec.c:
> cpu_breakpoint_insert -> Qemu-kvm.c: kvm_update_debugger
> Call an ioctl from Kvmctl.c:kvm_guest_debug that runs
> Vmx.c:set_guest_debug
>

Thanks for the pointers, Dor. It really helps digging the code.

Bests,
Jun

-------------------------------------------------------------------------
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/

Re: debug and breakpoint interrupts handling?

[Dong, Eddie]

kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org wrote:
> On 6/25/07, Dor Laor <dor.laor-atKUWr5tajBWk0Htik3J/w@public.gmane.org> 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.
vcpu->guest_debug.enabled is used for gdb guest thru host.


Guest DR register is not supported yet. See handle_dr of vmx.c


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/

Re: debug and breakpoint interrupts handling?

[Jun Koi]

On 6/25/07, Dong, Eddie <eddie.dong-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> wrote:
> kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org wrote:
> > On 6/25/07, Dor Laor <dor.laor-atKUWr5tajBWk0Htik3J/w@public.gmane.org> 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??

Thanks,
Jun

-------------------------------------------------------------------------
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/

Re: debug and breakpoint interrupts handling?

[Dor Laor]

>On 6/25/07, Dong, Eddie <eddie.dong-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> wrote:
>> kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org wrote:
>> > On 6/25/07, Dor Laor <dor.laor-atKUWr5tajBWk0Htik3J/w@public.gmane.org> 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.

>Thanks,
>Jun

-------------------------------------------------------------------------
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/

Re: debug and breakpoint interrupts handling?

[Avi Kivity]

Dor Laor wrote:
>>>> 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.
>   

This only happens if guest debugging is enabled (i.e. the host is 
debugging the guest).  However, if the guest is debugging itself, then 
these exceptions shouldn't be trapped.  Note that guest debugging and 
guest self debugging cannot be supported simultaneously using hardware 
debug support.


-------------------------------------------------------------------------
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/

Re: debug and breakpoint interrupts handling?

[Jun Koi]

On 6/25/07, Dor Laor <dor.laor-atKUWr5tajBWk0Htik3J/w@public.gmane.org> wrote:
> >On 6/25/07, Dong, Eddie <eddie.dong-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> wrote:
> >> kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org wrote:
> >> > On 6/25/07, Dor Laor <dor.laor-atKUWr5tajBWk0Htik3J/w@public.gmane.org> 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?

Thanks,
Jun

-------------------------------------------------------------------------
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/

Re: debug and breakpoint interrupts handling?

[Dong, Eddie]

Jun Koi wrote:
> On 6/25/07, Dor Laor <dor.laor-atKUWr5tajBWk0Htik3J/w@public.gmane.org> wrote:
>>> On 6/25/07, Dong, Eddie <eddie.dong-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> wrote:
>>>> kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org wrote:
>>>>> On 6/25/07, Dor Laor <dor.laor-atKUWr5tajBWk0Htik3J/w@public.gmane.org> 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/

Re: debug and breakpoint interrupts handling?

[Jun Koi]

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.

Any idea?

Thanks,
Jun


On 6/25/07, Dong, Eddie <eddie.dong-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> wrote:
> Jun Koi wrote:
> > On 6/25/07, Dor Laor <dor.laor-atKUWr5tajBWk0Htik3J/w@public.gmane.org> wrote:
> >>> On 6/25/07, Dong, Eddie <eddie.dong-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> wrote:
> >>>> kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org wrote:
> >>>>> On 6/25/07, Dor Laor <dor.laor-atKUWr5tajBWk0Htik3J/w@public.gmane.org> 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/

Re: debug and breakpoint interrupts handling?

[Dor Laor]

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


>
>Any idea?
>
>Thanks,
>Jun
>
>
>On 6/25/07, Dong, Eddie <eddie.dong-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> wrote:
>> Jun Koi wrote:
>> > On 6/25/07, Dor Laor <dor.laor-atKUWr5tajBWk0Htik3J/w@public.gmane.org> wrote:
>> >>> On 6/25/07, Dong, Eddie <eddie.dong-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> wrote:
>> >>>> kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org wrote:
>> >>>>> On 6/25/07, Dor Laor <dor.laor-atKUWr5tajBWk0Htik3J/w@public.gmane.org> 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/

Re: debug and breakpoint interrupts handling?

[Jun Koi]

On 6/27/07, Dor Laor <dor.laor-atKUWr5tajBWk0Htik3J/w@public.gmane.org> 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 <eddie.dong-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> wrote:
> >> Jun Koi wrote:
> >> > On 6/25/07, Dor Laor <dor.laor-atKUWr5tajBWk0Htik3J/w@public.gmane.org> wrote:
> >> >>> On 6/25/07, Dong, Eddie <eddie.dong-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> wrote:
> >> >>>> kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org wrote:
> >> >>>>> On 6/25/07, Dor Laor <dor.laor-atKUWr5tajBWk0Htik3J/w@public.gmane.org> 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/

Re: debug and breakpoint interrupts handling?

[Dor Laor]

>On 6/27/07, Dor Laor <dor.laor-atKUWr5tajBWk0Htik3J/w@public.gmane.org> 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/

Re: debug and breakpoint interrupts handling?

[Jun Koi]

On 6/28/07, Dor Laor <dor.laor-atKUWr5tajBWk0Htik3J/w@public.gmane.org> wrote:
> >On 6/27/07, Dor Laor <dor.laor-atKUWr5tajBWk0Htik3J/w@public.gmane.org> 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).

Ah, we are talking past each other here :-). I thought you mentioned
kvm_run() function instead of kvm_run structure. (The naming system in
KVM is quite confused)

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

Again, a misunderstanding here. I wanted to say that gdb client can be
used to modify the kernel of *guest VM*, rather than host kernel.

Many thanks,
Jun

-------------------------------------------------------------------------
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/

Compile error

[Dong, Eddie]

I saw compiler error at current head, does anybody else see too?
41ac4b23696b12fec15191969bc18da42359861d



make -C /lib/modules/2.6.21-rc3/build M=`pwd` "$@"
make[1]: Entering directory `/root/linux-2.6.21-rc3'
  LD      /root/work2/5th/kvm-userspace/kernel/built-in.o
  CC [M]  /root/work2/5th/kvm-userspace/kernel/svm.o
  CC [M]  /root/work2/5th/kvm-userspace/kernel/vmx.o
  CC [M]  /root/work2/5th/kvm-userspace/kernel/vmx-debug.o
  CC [M]  /root/work2/5th/kvm-userspace/kernel/kvm_main.o
/root/work2/5th/kvm-userspace/kernel/kvm_main.c:46:31:
linux/anon_inodes.h: No such file or directory
/root/work2/5th/kvm-userspace/kernel/kvm_main.c: In function
`create_vcpu_fd':
/root/work2/5th/kvm-userspace/kernel/kvm_main.c:2366: warning: implicit
declaration of function `anon_inode_getfd'
make[2]: *** [/root/work2/5th/kvm-userspace/kernel/kvm_main.o] Error 1
make[1]: *** [_module_/root/work2/5th/kvm-userspace/kernel] Error 2
make[1]: Leaving directory `/root/linux-2.6.21-rc3'
make: *** [all] Error 2

-------------------------------------------------------------------------
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/

Re: Compile error

[Dor Laor]

>I saw compiler error at current head, does anybody else see too?
>41ac4b23696b12fec15191969bc18da42359861d
>
>
>
>make -C /lib/modules/2.6.21-rc3/build M=`pwd` "$@"
>make[1]: Entering directory `/root/linux-2.6.21-rc3'
>  LD      /root/work2/5th/kvm-userspace/kernel/built-in.o
>  CC [M]  /root/work2/5th/kvm-userspace/kernel/svm.o
>  CC [M]  /root/work2/5th/kvm-userspace/kernel/vmx.o
>  CC [M]  /root/work2/5th/kvm-userspace/kernel/vmx-debug.o
>  CC [M]  /root/work2/5th/kvm-userspace/kernel/kvm_main.o
>/root/work2/5th/kvm-userspace/kernel/kvm_main.c:46:31:
>linux/anon_inodes.h: No such file or directory
>/root/work2/5th/kvm-userspace/kernel/kvm_main.c: In function
>`create_vcpu_fd':
>/root/work2/5th/kvm-userspace/kernel/kvm_main.c:2366: warning: implicit
>declaration of function `anon_inode_getfd'
>make[2]: *** [/root/work2/5th/kvm-userspace/kernel/kvm_main.o] Error 1
>make[1]: *** [_module_/root/work2/5th/kvm-userspace/kernel] Error 2
>make[1]: Leaving directory `/root/linux-2.6.21-rc3'
>make: *** [all] Error 2


This is the latest change of dropping kvmfs in favor of
anon_inode_getfd.
A matching code should be added to the external_kernel_compat.h file so
older kernels without anonfs could be used.

-------------------------------------------------------------------------
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/

Re: debug and breakpoint interrupts handling?

[Jun Koi]

On 6/25/07, Dong, Eddie <eddie.dong-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> wrote:
> kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org wrote:
> > On 6/25/07, Dor Laor <dor.laor-atKUWr5tajBWk0Htik3J/w@public.gmane.org> 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.

Dong, could you explain a bit: in which case interrupt 1/3 cause NMI,
and in which case they cause exception?


Thanks,
Jun

-------------------------------------------------------------------------
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/

Re: debug and breakpoint interrupts handling?

[Dong, Eddie]

>> This exit reason is either NMI, or software interrupt or exception.
> 
> Dong, could you explain a bit: in which case interrupt 1/3 cause NMI,
> and in which case they cause exception?

If you set the bitmap for INT 1/3 in EXCEPTION_BITMAP (refer
update_exception_bitmap), you will see
VM Exit for guest INT 1/3, otherwise it is all in guest world.

I don't mean int 1/3 VM Exit can be a NMI VM exit, but the exit reason 0
(EXIT_REASON_EXCEPTION_NMI) can be 
either a NMI, or software interrupt or exception. See SDM for reason 0
explaination.
thx,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/

Re: debug and breakpoint interrupts handling?

[Jun Koi]

On 6/27/07, Dong, Eddie <eddie.dong-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> wrote:
>
> >> This exit reason is either NMI, or software interrupt or exception.
> >
> > Dong, could you explain a bit: in which case interrupt 1/3 cause NMI,
> > and in which case they cause exception?
>
> If you set the bitmap for INT 1/3 in EXCEPTION_BITMAP (refer
> update_exception_bitmap), you will see
> VM Exit for guest INT 1/3, otherwise it is all in guest world.
>
> I don't mean int 1/3 VM Exit can be a NMI VM exit, but the exit reason 0
> (EXIT_REASON_EXCEPTION_NMI) can be
> either a NMI, or software interrupt or exception. See SDM for reason 0
> explaination.

OK, the part "NMI can be software interrupt or exception" is a bit
confused in the context, hence my question :-)

Thanks,
Jun

-------------------------------------------------------------------------
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/

Re: debug and breakpoint interrupts handling?

[Gregory Haskins]

On Wed, 2007-06-27 at 12:51 +0900, Jun Koi 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.
> 
> Any idea?

Its probably not a real-world concern since you wouldn't be debugging in
production.  But, if it was a concern to someone you could do things to
qemu to shore this up a little bit.  For instance, bind the gdb-proxy to
the "localhost" address, or alternatively open a gdb transport over a
unix-domain-socket with appropriate perms instead of IP, etc.

-Greg


-------------------------------------------------------------------------
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/

Re: debug and breakpoint interrupts handling?

[Jun Koi]

On 6/27/07, Gregory Haskins <ghaskins-Et1tbQHTxzrQT0dZR+AlfA@public.gmane.org> wrote:
> On Wed, 2007-06-27 at 12:51 +0900, Jun Koi 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.
> >
> > Any idea?
>
> Its probably not a real-world concern since you wouldn't be debugging in
> production.  But, if it was a concern to someone you could do things to
> qemu to shore this up a little bit.  For instance, bind the gdb-proxy to
> the "localhost" address, or alternatively open a gdb transport over a
> unix-domain-socket with appropriate perms instead of IP, etc.
>

I like the domain socket idea, but naturally gdb does not support that
kind of communication, but only network and serial line, does it?


Thanks,
Jun

-------------------------------------------------------------------------
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/

Re: debug and breakpoint interrupts handling?

[Gregory Haskins]

On Wed, 2007-06-27 at 13:33 +0900, Jun Koi wrote:
> On 6/27/07, Gregory Haskins <ghaskins-Et1tbQHTxzrQT0dZR+AlfA@public.gmane.org> wrote:
> > On Wed, 2007-06-27 at 12:51 +0900, Jun Koi 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.
> > >
> > > Any idea?
> >
> > Its probably not a real-world concern since you wouldn't be debugging in
> > production.  But, if it was a concern to someone you could do things to
> > qemu to shore this up a little bit.  For instance, bind the gdb-proxy to
> > the "localhost" address, or alternatively open a gdb transport over a
> > unix-domain-socket with appropriate perms instead of IP, etc.
> >
> 
> I like the domain socket idea, but naturally gdb does not support that
> kind of communication, but only network and serial line, does it?

Since its all open-source, it will support anything you code it to do ;)
In a past life, I modified it to work over a proprietary IPC mechanism
and it worked great.

But on that subject, I bet there are tools out there that might do the
conversion for you (socat?) without modifying any code.

> 
> 
> Thanks,
> Jun


-------------------------------------------------------------------------
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/

Re: debug and breakpoint interrupts handling?

[Jun Koi]

On 6/27/07, Gregory Haskins <ghaskins-Et1tbQHTxzrQT0dZR+AlfA@public.gmane.org> wrote:
> On Wed, 2007-06-27 at 13:33 +0900, Jun Koi wrote:
> > On 6/27/07, Gregory Haskins <ghaskins-Et1tbQHTxzrQT0dZR+AlfA@public.gmane.org> wrote:
> > > On Wed, 2007-06-27 at 12:51 +0900, Jun Koi 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.
> > > >
> > > > Any idea?
> > >
> > > Its probably not a real-world concern since you wouldn't be debugging in
> > > production.  But, if it was a concern to someone you could do things to
> > > qemu to shore this up a little bit.  For instance, bind the gdb-proxy to
> > > the "localhost" address, or alternatively open a gdb transport over a
> > > unix-domain-socket with appropriate perms instead of IP, etc.
> > >
> >
> > I like the domain socket idea, but naturally gdb does not support that
> > kind of communication, but only network and serial line, does it?
>
> Since its all open-source, it will support anything you code it to do ;)

Sure, but I were just wondering if I can do that without modiying gdb
client  ;-)

> In a past life, I modified it to work over a proprietary IPC mechanism
> and it worked great.
>
> But on that subject, I bet there are tools out there that might do the
> conversion for you (socat?) without modifying any code.
>

OK, but socat cannot prevent local attacks.

Thanks,
Jun

-------------------------------------------------------------------------
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/