Setting hardware breakpoints in guest OS

Setting hardware breakpoints in guest OS

[duck-j34lQMj1tz/QT0dZR+AlfA]

Can hardware breakpoints be set (and trapped, and handled) inside a guest
OS (specifially Windows XP2)?

I noticed the other day that software (malicious code, in fact) packed with
the EXE compressor PELock won't run under QEMU+KVM. I guessed that this was
because h/w breakpoints aren't being trapped. (The PELock incarnation used
in this case relies on SEH and H/W breaks -- verifying that they take place
correctly -- in its decryption code in order to try to make it harder to
extract the original content from packed files.)

A quick try with OllyDbg suggested that I wasn't able to provoke hardware
traps in my own code, either. Olly allows me to specify a H/W breakpoint
but I never seem to get control back at the desired address. INT 1 and INT
3 debugging work just fine (i.e. tracing and software breakpoints).

Is this "one of those things" to do with virtualisation? QEMU+kqemu handles
PELock files just fine.

Apologies if this is an already-answered question. I couldn't find an
answer on my own.


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace

Re: Setting hardware breakpoints in guest OS

[Avi Kivity]

duck-j34lQMj1tz/QT0dZR+AlfA@public.gmane.org wrote:
> Can hardware breakpoints be set (and trapped, and handled) inside a guest
> OS (specifially Windows XP2)?
>
> I noticed the other day that software (malicious code, in fact) packed with
> the EXE compressor PELock won't run under QEMU+KVM. I guessed that this was
> because h/w breakpoints aren't being trapped. (The PELock incarnation used
> in this case relies on SEH and H/W breaks -- verifying that they take place
> correctly -- in its decryption code in order to try to make it harder to
> extract the original content from packed files.)
>
> A quick try with OllyDbg suggested that I wasn't able to provoke hardware
> traps in my own code, either. Olly allows me to specify a H/W breakpoint
> but I never seem to get control back at the desired address. INT 1 and INT
> 3 debugging work just fine (i.e. tracing and software breakpoints).
>
> Is this "one of those things" to do with virtualisation? QEMU+kqemu handles
> PELock files just fine.

While we tried to make debugging inside the guest work, this was never 
really tested, so it's likely broken.  I'll try to look at what it will 
take to make it work; I don't think there's much needed.

What hardware are you using?  If you have both AMD and Intel hardware, 
you might have better luck switching, since this is very subarch dependent.

-- 
Any sufficiently difficult bug is indistinguishable from a feature.


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace

Re: Setting hardware breakpoints in guest OS

[duck-j34lQMj1tz/QT0dZR+AlfA]

>While we tried to make debugging inside the guest work, this
>was never really tested, so it's likely broken.  I'll try to
>look at what it will take to make it work; I don't think there's
>much needed.

That sounds encouraging -- I had imagined there might be some
"impossibility factor" in sharing something like hardware breakpoints
between host and guest.

For now I'm simply sticking to QEMU+kqemu when I expect deliberate
trickiness or need to do hard-breakpoint debugging, and QEMU/KVM (which is
up to 50% faster when doing Windows software builds on my PC, nice!) when I
don't care.

I haven't had any problems loading and using the kvm drivers and kqemu at
the same time, and I have assumed that there ought to be no issues in doing
so, since they work quite differently and (from my very dangerously limited
understanding) ought not to be competing for any mutually exclusive
hardware resources. Is that a reasonable assumption?

>What hardware are you using?  If you have both AMD and Intel
>hardware, you might have better luck switching, since this is
>very subarch dependent.

Intel Core Duo (T2400 @ 1.83GHz according to /proc/cpuinfo), running 32-bit
Linux 2.6.21.5 using KVM drivers built from the kvm-59 sourceball.

Sorry, I don't have other vendors or CPU bitnesses to test on.

PS: When I build KVM "out of the box," I get a qemu binary called
qemu-system-x86_64, though I have a 32-bit CPU and a 32-bit OS. Forgive my
ignorance on this, but...why does the name of the binary imply a 64-bit
flavour?


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace

Re: Setting hardware breakpoints in guest OS

[Avi Kivity]

duck-j34lQMj1tz/QT0dZR+AlfA@public.gmane.org wrote:
>> While we tried to make debugging inside the guest work, this
>> was never really tested, so it's likely broken.  I'll try to
>> look at what it will take to make it work; I don't think there's
>> much needed.
>>     
>
>   

Thinking a bit, it may well be broken only when using the external 
module.  If you use a distro-provided kvm (or compile your own kernel 
with kvm included) then it might work.

Then again, distro provided kvms tend to be old and therefore slow.

> That sounds encouraging -- I had imagined there might be some
> "impossibility factor" in sharing something like hardware breakpoints
> between host and guest.
>
>   

Both vmx and svm fully allow virtualizing the hardware breakpoints (and 
even things like last branch recording).

> For now I'm simply sticking to QEMU+kqemu when I expect deliberate
> trickiness or need to do hard-breakpoint debugging, and QEMU/KVM (which is
> up to 50% faster when doing Windows software builds on my PC, nice!) when I
> don't care.
>
> I haven't had any problems loading and using the kvm drivers and kqemu at
> the same time, and I have assumed that there ought to be no issues in doing
> so, since they work quite differently and (from my very dangerously limited
> understanding) ought not to be competing for any mutually exclusive
> hardware resources. Is that a reasonable assumption?
>   

I believe so.  I know VirtualBox and VMware have problems coexisting 
with kvm (since they tend to switch to real mode which is forbidden by 
vmx), but if kqemu works, then there shouldn't be any hidden problems.

>   
>> What hardware are you using?  If you have both AMD and Intel
>> hardware, you might have better luck switching, since this is
>> very subarch dependent.
>>     
>
> Intel Core Duo (T2400 @ 1.83GHz according to /proc/cpuinfo), running 32-bit
> Linux 2.6.21.5 using KVM drivers built from the kvm-59 sourceball.
>
> Sorry, I don't have other vendors or CPU bitnesses to test on.
>
> PS: When I build KVM "out of the box," I get a qemu binary called
> qemu-system-x86_64, though I have a 32-bit CPU and a 32-bit OS. Forgive my
> ignorance on this, but...why does the name of the binary imply a 64-bit
> flavour?
>   

The qemu binary is 32-bit, but is capable of running a 64-bit guest if 
you have a 64-bit cpu and a 64-bit kernel (still retaining 32-bit 
userspace).

You can generate a 32-bit only binary, but that does not have any 
advantages over the 64-bit capable binary.

Yes, it confuses me too.

-- 
error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace