bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

GDB testsuite: »Memory at address 0 is possibly executable«


From: Thomas Schwinge
Subject: GDB testsuite: »Memory at address 0 is possibly executable«
Date: Thu, 11 Sep 2014 16:23:04 +0200
User-agent: Notmuch/0.9-101-g81dad07 (http://notmuchmail.org) Emacs/24.3.1 (x86_64-pc-linux-gnu)

Hi!

I've noticed that you guys have recently done some changes in GNU Mach's
vm_map or thereabouts, and -- I presume -- that is affecting the GDB
testsuite in that tests that used to PASS are now no longer considered
for execution, because »Memory at address 0 is possibly executable«:

    # If we can examine what's at memory address 0, it is possible that we
    # could also execute it.  This could probably make us run away,
    # executing random code, which could have all sorts of ill effects,
    # especially on targets without an MMU.  Don't run the tests in that
    # case.
    
    if { [is_address_zero_readable] } {
        untested "Memory at address 0 is possibly executable"
        return
    }

gdb/testsuite/lib/gdb.exp:is_address_zero_readable:

    # Return 1 if the memory at address zero is readable.
    
    gdb_caching_proc is_address_zero_readable {
        global gdb_prompt
    
        set ret 0
        gdb_test_multiple "x 0" "" {
            -re "Cannot access memory at address 0x0.*$gdb_prompt $" {
                set ret 0
            }
            -re ".*$gdb_prompt $" {
                set ret 1
            }
        }
    
        return $ret
    }

So, something is really being mapped to and accessible at 0x0:

    $ gdb -q /bin/true
    Reading symbols from /bin/true...(no debugging symbols found)...done.
    (gdb) break exit
    Breakpoint 1 at 0x8048cd0
    (gdb) r
    Starting program: /bin/true 
    [New Thread 24498.5]
    
    Breakpoint 1, exit (status=0) at exit.c:103
    103     exit.c: No such file or directory.
    (gdb) x 0
    0x0:    0x464c457f
    (gdb) print *(int *)0 = 0x1234
    $1 = 4660
    (gdb) x 0
    0x0:    0x00001234

Memory map:

    $ vminfo 24498
             0[0x1000] (prot=RX, max_prot=RWX, mem_obj=46)
        0x1000[0xe000] (prot=RX, max_prot=RWX, mem_obj=46, offs=0x1000)
        0xf000[0x1000] (prot=RX, max_prot=RWX, mem_obj=46)
       0x10000[0x16000] (prot=RX, max_prot=RWX, mem_obj=46, offs=0x10000)
       0x26000[0x1000] (prot=R, max_prot=RWX, mem_obj=46)
       0x27000[0x1000] (prot=RW, max_prot=RWX, mem_obj=46)
       0x28000[0x1000] (prot=0, max_prot=RWX)
       0x29000[0xfff000] (prot=RWX, mem_obj=47)
     0x1028000[0x1000] (prot=RWX, mem_obj=47, offs=0xfff000)
     0x1029000[0x1000] (prot=RW, max_prot=RWX, mem_obj=48)
     0x102a000[0x1000] (prot=RW, max_prot=RWX, mem_obj=49)
     0x102c000[0x2000] (prot=RW, max_prot=RWX, mem_obj=49, offs=0x2000)
     0x102e000[0x1000] (prot=RW, max_prot=RWX, mem_obj=50)
     0x102f000[0xb000] (prot=R, max_prot=RWX, mem_obj=51)
     0x103a000[0x61000] (prot=RX, max_prot=RWX, mem_obj=52)
     0x109b000[0x1000] (prot=RX, max_prot=RWX, mem_obj=52)
     0x109c000[0x155000] (prot=RX, max_prot=RWX, mem_obj=52, offs=0x62000)
     0x11f1000[0x3000] (prot=R, max_prot=RWX, mem_obj=52)
     0x11f4000[0x2000] (prot=RW, max_prot=RWX, mem_obj=52, offs=0x3000)
     0x11f6000[0x4000] (prot=RW, max_prot=RWX, mem_obj=53)
     0x11fa000[0x15000] (prot=RX, max_prot=RWX, mem_obj=54)
     0x120f000[0x1000] (prot=R, max_prot=RWX, mem_obj=54)
     0x1210000[0x1000] (prot=RW, max_prot=RWX, mem_obj=54, offs=0x1000)
     0x1211000[0x1000] (prot=RW, max_prot=RWX, mem_obj=55)
     0x1212000[0x30000] (prot=RX, max_prot=RWX, mem_obj=56)
     0x1242000[0x1000] (prot=R, max_prot=RWX, mem_obj=56)
     0x1243000[0x1000] (prot=RW, max_prot=RWX, mem_obj=56, offs=0x1000)
     0x1244000[0x2000] (prot=RW, max_prot=RWX, mem_obj=57)
     0x1246000[0x1000] (prot=0, max_prot=RWX, mem_obj=57, offs=0x2000)
     0x1247000[0x8000] (prot=RW, max_prot=RWX, mem_obj=57, offs=0x3000)
     0x124f000[0x1000] (prot=RW, max_prot=RWX, mem_obj=58)
     0x8048000[0x1000] (prot=RX, max_prot=RWX, mem_obj=59)
     0x8049000[0x5000] (prot=RX, max_prot=RWX, mem_obj=59, offs=0x1000)
     0x804e000[0x1000] (prot=R, max_prot=RWX, mem_obj=59)
     0x804f000[0x1000] (prot=RW, max_prot=RWX, mem_obj=59)
     0x8050000[0x21000] (prot=RWX)
     0x8071000[0x7fdf000] (prot=0, max_prot=RWX, offs=0x21000)

Actually...:

    (gdb) info sharedlibrary 
    From        To          Syms Read   Shared Object Library
    0x00000db0  0x0001d959  Yes         /lib/ld.so
    0x01057890  0x0119d9e4  Yes         /lib/i386-gnu/libc.so.0.3
    0x011fd7d0  0x0120b21f  Yes         /lib/i386-gnu/libmachuser.so.1
    0x012198f0  0x01239bcb  Yes         /lib/i386-gnu/libhurduser.so.0.3

    $ ldd /bin/true
            libc.so.0.3 => /lib/i386-gnu/libc.so.0.3 (0x0103a000)
            /lib/ld.so => /lib/ld.so.1 (0x00000000)
            libmachuser.so.1 => /lib/i386-gnu/libmachuser.so.1 (0x011fa000)
            libhurduser.so.0.3 => /lib/i386-gnu/libhurduser.so.0.3 (0x01212000)

The dynamic linker loading straight to 0x0 is most likely not what you
intended?  ;-)


Grüße,
 Thomas

Attachment: pgp7t8FCf1iMq.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]