Re: [Qemu-discuss] Unable to debug 2.5.0 qemu-system-ppc64.exe with gdb

[Jakob Bohm]

On 08/04/2016 13:50, address@hidden wrote:
> In order to find out where certain QEMU functions are called from, 
> using test output is not practical.
> Therefore I set out to use gdb to debug qemu-system-ppc64.exe (the 
> unstripped version):
>
> gdb /cygdrive/c/MinGW/msys/1.0/local/qemu/qemu-system-ppc64
> b pci_host_config_write_common
>
> gdb responds with:
>
> Breakpoint 1 at 0x6ecd79: file 
> C:/MinGW/msys/1.0/gnu_dev/qemu-2.5.0/hw/pci/pci_host.c, line 54.
>
> Next I issue an r-command with the same options as I need to use:
>
> r -m 240 -g 640x400x16 -name ppc -M ppce500 -cpu e5500 -bios 
> u-boot.e500 -icount 2 -gdb tcp:127.0.0.1:1234,ipv4 -netdev 
> tap,id=vlan0,ifname=tap0 -device 
> virtio-net-pci,netdev=vlan0,id=virtio,bus=pci.0,addr=1.0, -kernel 
> Boot.bin -initrd Boot.qemu -device VGA -vga std
>
> The gdb response here is:
>
> [New Thread 9180.0x1c94]
> Warning:
> Cannot insert breakpoint 1.
> Error accessing memory address 0x6ecd54: Input/output error.
>
> I then delete breakpoint 1 (del 1), and continue (c), and the program 
> starts running
>
> gdb outputs
> [New Thread 9180.0x12b8]
>    ... (my test output lines) ...
> [New Thread 9180.0x2234]
> [New Thread 9180.0x233c]
> ...
>
> and everything happens as usually, except I have not achieved the goal 
> of hitting any breakpoints.
>
> Upon closer examination it appears that the qemu-system-ppc64.exe that 
> is linked to 0x400000 and up as any other Windows application, in fact 
> has been moved up higher in the address space a number of pages, but 
> not always the same number. I have seen 0xb600000 be the bias, and 
> also 0x4c0000 and others. I found out by letting one of my test output 
> lines print the current EIP-value, as well as the (linked) address of 
> the function this happens inside. The 2 values were close to each 
> other as expected, and both were biased.
> I must assume that the move of the qemu-system-ppc64.exe sections 
> means that this executable contains fixup relocations like what the 
> objdump tool reports:
Actually, you are seeing that the Windows version you
use supports ASLR (Address Space Layout Randomization)
to reduce the risk that buffer overflow vulnerabilities
can be effectively exploited.

If gdb fails to adjust correctly to the resulting
relocation of the program, this would be a serious
gdb bug, given that ASLR is also implemented (though
differently) on Linux based systems.

It is possible (as you suggest yourself) to disable
ASLR for a windows exe by either:

A) Stripping away the relocations so the exe can only
  be loaded at the default address specified in the
  PE header.

B) Clearing/Setting one of the EXE feature flags (the
  one named "/DYNAMICBASE:NO" in Microsoft tools) in
  the PE header.

Of cause, doing this is enough of a security
disadvantage that Microsoft is releasing critical
security patches for any Microsoft program that has
been released with ASLR disabled, so it should only
be done while debugging.

> /cygdrive/c/MinGW/msys/1.0/local/qemu/qemu-system-ppc64.exe:   file 
> format pei-i386
>
> Sections:
> Idx Name  Size      VMA       LMA   File off  Algn
>   0 .text   0086e6cc  00401000  00401000  00000600  2**4
>         CONTENTS, ALLOC, LOAD, READONLY, CODE, DATA
>   1 .data   0007fbf4  00c70000  00c70000  0086ee00  2**5
>         CONTENTS, ALLOC, LOAD, DATA
>   2 .rdata  0027d17c  00cf0000  00cf0000  008eea00  2**5
>         CONTENTS, ALLOC, LOAD, READONLY, DATA
>   3 .eh_frame     000d8bd4  00f6e000  00f6e000  00b6bc00  2**2
>         CONTENTS, ALLOC, LOAD, READONLY, DATA
>   4 .bss    004583c4  01047000  01047000  00000000  2**5
>         ALLOC
>   5 .edata  00001219  014a0000  014a0000  00c44800  2**2
>         CONTENTS, ALLOC, LOAD, READONLY, DATA
>   6 .idata  0000311c  014a2000  014a2000  00c45c00  2**2
>         CONTENTS, ALLOC, LOAD, DATA
>   7 .CRT    00000018  014a6000  014a6000  00c48e00  2**2
>         CONTENTS, ALLOC, LOAD, DATA
>   8 .tls    00000020  014a7000  014a7000  00c49000  2**2
>         CONTENTS, ALLOC, LOAD, DATA
>   9 .rsrc   0000176c  014a8000  014a8000  00c49200  2**2
>         CONTENTS, ALLOC, LOAD, DATA
>  10 .reloc  00066440  014aa000  014aa000  00c4aa00  2**2
>         CONTENTS, ALLOC, LOAD, READONLY, DATA
>  11 .debug_aranges 00005198  01511000  01511000  00cb1000  2**0
>         CONTENTS, READONLY, DEBUGGING
>  12 .debug_info   00bca2a4  01517000  01517000  00cb6200  2**0
>         CONTENTS, READONLY, DEBUGGING
>  13 .debug_abbrev 00078c18  020e2000  020e2000  01880600  2**0
>         CONTENTS, READONLY, DEBUGGING
>  14 .debug_line   001a8dce  0215b000  0215b000  018f9400  2**0
>         CONTENTS, READONLY, DEBUGGING
>  15 .debug_str    0005ceb2  02304000  02304000  01aa2200  2**0
>         CONTENTS, READONLY, DEBUGGING
>  16 .debug_loc    00098cb6  02361000  02361000  01aff200  2**0
>         CONTENTS, READONLY, DEBUGGING
>  17 .debug_ranges 0000d9e0  023fa000  023fa000  01b98000  2**0
>         CONTENTS, READONLY, DEBUGGING
Note that the above output also indicates that the used
version of objdump seems to parse COFF section descriptors
incorrectly.  Each descriptor contains the following
size/offset related numbers:

- Location in memory after loading (shown TWICE in the above output)
- Location in file before loading (shown)
- Size in memory after loading (this or the next one not shown above)
- Size in file before loading (this or the previous one not shown above)

> I am using GNU gdb:
>
>          (GDB) 7.6.50.20130728-cvs (cygwin-special)
>
> Is there a way to have this work?
> Is it important that relocation takes place, or could it be fixed in 
> the virtual address space as its usual 0x400000 location?
>
> I noticed the building of QEMU has -fPIC at least for compilation of 
> at least some files, but also --static.
> Though I am only building this particular qemu-system-ppc64 variant, 
> it still takes me almost an hour to experiment with other compile and 
> link options.
>
> Any help is highly appreciated!
>
>         Thorkil B. Rasmussen


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded