magic breakpoints problem on XP ntldr

[therealdreg]

ntldr.zip

On Windows XP SP3:

Enable magic-break-points with bochs debugger

It breaks every time, you cant continue (a lot of magic breakpoints):

(0) Magic breakpoint
(0) Magic breakpoint
(0) Magic breakpoint
(0) Magic breakpoint
(0) Magic breakpoint
(0) Magic breakpoint

bochsdbg.exe
========================================================================
                        Bochs x86 Emulator 2.7
              Built from SVN snapshot on August  1, 2021
                Timestamp: Sun Aug  1 10:07:00 CEST 2021
========================================================================
00000000000i[      ] reading configuration from .bochsrc
00000000000e[      ] .bochsrc:782: ataX-master/slave CHS set to 0/0/0 - autodetection enabled
00000000000e[      ] .bochsrc:783: ataX-master/slave CHS set to 0/0/0 - autodetection enabled
00000000000i[      ] Stopping on magic break points
00000000000i[      ] installing win32 module as the Bochs GUI
00000000000i[      ] using log file bochsout.txt
Next at t=0
(0) [0x0000fffffff0] f000:fff0 (unk. ctxt): jmpf 0xf000:e05b          ; ea5be000f0
<bochs:1> c
(0) Magic breakpoint
Next at t=4287923
(0) [0x000000020264] 2000:0000000000000264 (unk. ctxt): jmp .+1  (0x00020267)     ; eb01
<bochs:2> c
(0) Magic breakpoint
Next at t=4570603
(0) [0x000000020257] 2000:0000000000000257 (unk. ctxt): nop                       ; 90
<bochs:3> c
(0) Magic breakpoint
Next at t=4571118
(0) [0x000000020257] 2000:0000000000000257 (unk. ctxt): nop                       ; 90
<bochs:4> c
(0) Magic breakpoint
Next at t=4571699
(0) [0x000000020257] 2000:0000000000000257 (unk. ctxt): nop                       ; 90
<bochs:5> c
(0) Magic breakpoint
Next at t=4572761
(0) [0x000000020257] 2000:0000000000000257 (unk. ctxt): nop                       ; 90
<bochs:6> c
(0) Magic breakpoint
Next at t=4573864
(0) [0x000000020257] 2000:0000000000000257 (unk. ctxt): nop                       ; 90
<bochs:7> c
(0) Magic breakpoint
Next at t=4575039
(0) [0x000000020257] 2000:0000000000000257 (unk. ctxt): nop                       ; 90
<bochs:8>

[therealdreg]

The reason is.... windows xp ntldr have code like this:

0000000000020252: (                    ): mov cr0, eax              ; 0f22c0
0000000000020255: (                    ): xchg bx, bx               ; 87db
0000000000020257: (                    ): nop                       ; 90

And this code is called a lot of times!

A ring3 code CANT execute OUT instruction so disable magic_breakpoints + use 0x8AE0 as workarround is not a solution

[therealdreg]

A workarround for ring0 code can be use advanced debugger plugin:

0x8AE0 - Return to Debugger Prompt

 If the debugger is enabled (via --enable-debugger), sending 0x8AE0 to port 0x8A00
 after the device has been enabled will return the Bochs to the debugger prompt.
 Basically the same as doing CTRL+C.

https://bochs.sourceforge.io/doc/docbook/development/debugger-advanced.html

BochsBP macro
        ; https://c9x.me/x86/html/file_module_x86_id_222.html
        
        ; https://bochs.sourceforge.io/doc/docbook/development/debugger-advanced.html

        nop
        push eax
        push edx
        
        mov ax, 8A00h
        mov dx, 8A00h
        out dx, ax
        
        mov ax, 08AE0h
        out dx, ax
        
        pop edx
        pop eax
        nop
endm

[therealdreg]

Solved PR #58 !

[Nable80]

Is there a JMP instruction after that NOP?
I found a comment for CR0 loading:

The following JMP must be DWORD-aligned in order to avoid an obscure i386 hardware bug.
If it isn't, it is possible that the prefetch queue can get trashed.

Some years ago I was quite surprised by finding xchg bx, bx in an ancient BIOS image that definitely predates Bochs.
Your sample makes me assured that this is just a 2-byte NOP (or a part of a longer one) that is emitted by ALIGN macro of some MASM versions.

[therealdreg]

Hey @Nable80, thanks for your point, it's very interesting (I uploaded the ntdlr file in the initial message, take a look if you want)

As you noticed, first break have a JMP instruction after that :

Others no:

BUT, as you know it seems like a padding stuff, but this time for 3 bytes: with xchg bx, bx + 0x90

I wasn't aware of this padding due to the ALIGN macro of some MASM versions. It's good to know

The following JMP must be DWORD-aligned in order to avoid an obscure i386 hardware bug.
If it isn't, it is possible that the prefetch queue can get trashed.

Very interesting, good catch @Nable80, thx