Hacker News Reader

Comment by xtacy | Hacker News Reader

The fundamental mechanism: Setting a breakpoint at a particular instruction requires overwriting the instruction at the address to "int 0x3" (which is exactly 1 byte long).

Something nice to think about: why should the breakpoint interrupt instruction be exactly 1 byte long?

View on HN

Actually, it doesn't have to be. There are 3 forms of the interrupt instruction. 2 1 byte versions for specifying either int 3 or int 4, and a 2 byte version that can specify any interrupt number. It's possible to use either the one byte or 2 byte versions of int 3. Also, by adding arbitrary instruction prefixes (for the "int" instruction the are meaningless) it's possible to specify a breakpoint using anywhere from 1 to 15 bytes.

However, their really is no reason to use more space than necessary. If you can encode an instruction with 1 byte, it doesn't make any sense to encode it using any more bytes then what you need. Every byte that gets updated when a break point is set needs to be backed up and restored once the breakpoint is hit. Using extra bytes will hurt runtime performance.

This is particularly true given the "ptrace" interface on Linux. It only supports reading or writing a single word (2 bytes) of memory in the target process at a time. Backing up and restoring any more than 2 bytes would require extra calls into the kernel, plus extra memory barriers to ensure caches get updated. Using a scheme that did that more than once would just waste CPU cycles.

Why do you say a single word is 2 bytes?

On most systems, 1 byte == 8 bits, 1 word == 16 bits, 1 dword (double word) == 32 bits, etc.

This sounds like Windows terminology. I'm pretty sure on 32-bit Linux a word is 32 bits, and ptrace reads 32-bit chunks and not 16-bit chunks.

You're thinking too high-level. We're talking about a "word" in x86 instruction set parlance. It's an artifact of the old 16-bit computing days. Nothing to do with the OS.

I agree that we should't deviate from the subject too much. My reply was intended to fix the generally incorrect comment regarding the size of the word read by ptrace.

In ptrace:

> The size of a "word" is determined by the OS variant (e.g., for 32-bit Linux it's 32 bits, etc.).

Taken from http://linux.die.net/man/2/ptrace

In x86 assembly (and a lot of other contexts), 16 bits are called a word (a left over from 16 bit days when 16 bits were in fact a machine word), and larger data types are named dword (double word, 32 bits), qword (quad word, 64 bits), and so on. This terminology is even included in certain instruction mnemonics (movsb|movsw|movsd, ...).

In ptrace:

> The size of a "word" is determined by the OS variant (e.g., for 32-bit Linux it's 32 bits, etc.).

Taken from http://linux.die.net/man/2/ptrace

I think you missed the issue.

Consider the following code:

       jmp foo
       push ax        // 50
  foo: int 21h        // CD 21

So now we want to set a breakpoint on the "push ax". If we do it using more than a single byte, it will overwrite the int 21h instruction and the code will mess up and likely crash.

That's why 1 byte is used for breakpoints.

requires overwriting the instruction

Not quite. Some processors, including X86, have hardware support for breakpoints (http://en.wikipedia.org/wiki/X86_debug_register). It may also be possible to (mis)use virtual memory hardware for setting breakpoints. Also [pedantic], one overwrites a byte, not an instruction.

Using a single byte is necessary because the program could jump to (address+1). If that address contained part of the breakpoint code, program semantics could change. O, and jumping to (address+1) could even be useful if address contains a multi-byte instruction.

Could you elaborate on your "jump to (address+1)" argument? Why does this make a single-byte "int 3" necessary?

Consider this sequence:

     0041301E  33 D2     xor edx, edx
     00413020  83 E8 02  sub eax, 2
     00413023  74 01     jz loc_00413026
     00413025  4A        dec edx
     00413026  ...

Without a single-byte int 3, a break on dec edx will mess up everything if that branch is not taken.

Give a sequence like (using Intel mnemonics):

        mov eax,[x]
        or  eax,eax
        jz  foo
        dec eax
    foo call bar

The instruction "dec eax" is one byte in size. If you want to place a breakpoint there, and you used the two byte form of "int 3", then when the code did the "jz foo" (jump if the previous result was zero to location foo) the "call bar" instruction would be partially overwritten and form a new instruction. If the condition leading the breakpoint isn't taken, you now have some other instruction (it ends up being an "add" instruction) which is bad.

That's why there's a one byte version of "int 3", because there are one byte instructions.

Yep, this is what I meant in my own comment: http://news.ycombinator.net/item?id=2132005

Just thought you're referring to something else. Thanks for clearing this up; I hope you don't mind if I use your example in the next part of the series. :-)

Additionally with modern x86 you can set breakpoints using the special debug registers

http://en.wikipedia.org/wiki/X86_debug_register

I can think of a couple of reasons. For example, it's convenient because 1 byte is the minimal length of an instruction in x86.

Reply on news.ycombinator.com