# Hacking/Debugging nullfs - KGDB cannot access memory at address



## Pegasus711 (May 24, 2017)

I am trying to hack/understand the nullfs kernel module so to that end, I do the following:

On the target machine: kldstat gives:


```
Id Refs Address            Size     Name
 1   10 0xffffffff80200000 17e10c8  kernel
2    1 0xffffffff819e2000 4cf0     vmxnet.ko
3    1 0xffffffff819e7000 16e0     echo.ko
4    1 0xffffffff81c11000 23dc     vmmemctl.ko
5    1 0xffffffff81c14000 641b     nullfs.ko

nm /boot/kernel/nullfs.ko | grep mount
00000000000018f0 t null_getwritemount
0000000000000540 t nullfs_mount
0000000000000930 t nullfs_unmount
                 U vfs_mountedfrom
                 U vop_getwritemount_desc
```

On the local machine which connects to the target via a named pipe acting as a serial console (I am using virtual machines):


```
(kgdb) tr0
kdb_sysctl_enter (oidp=<value optimized out>, arg1=<value optimized out>,
arg2=0xfffffe004e7cc7f0,
   req=<value optimized out>) at /usr/src/sys/kern/subr_kdb.c:446
446                     kdb_why = KDB_WHY_UNSET;
Current language:  auto; currently minimal
(kgdb) getsyms
During symbol reading, Incomplete CFI data; unspecified registers at
0xffffffff8099497a.
Id Refs Address    Size     Name
1   10 0x80200000 17e10c8  kernel
2    1 0x819e2000 4cf0     vmxnet.ko
3    1 0x819e7000 16e0     echo.ko
4    1 0x81c11000 23dc     vmmemctl.ko
5    1 0x81c14000 641b     nullfs.ko
Select the list above with the mouse, paste into the screen
and then press ^D.  Yes, this is annoying.
5    1 0x81c14000 641b     nullfs.ko
add symbol table from file
"/usr/obj/usr/src/sys/AIJAZ-DEBUG/modules/usr/src/sys/modules/nullfs/nullfs.ko.debug"
at
        .text_addr = 0x81c14000
        .data_addr = 0x81c14000
        .bss_addr = 0x81c14000
(kgdb) add-kld nullfs.ko
add symbol table from file "/boot/kernel/nullfs.ko.symbols" at
        .text_addr = 0xffffffff81c14000
        set_sysinit_set_addr = 0xffffffff81c15c90
        set_sysuninit_set_addr = 0xffffffff81c15cb0
        .rodata.str1.1_addr = 0xffffffff81c15cc8
        set_modmetadata_set_addr = 0xffffffff81c15e48
        set_sysctl_set_addr = 0xffffffff81c15e58
        .data_addr = 0xffffffff81c15e60
        .bss_addr = 0xffffffff81c16360
(y or n) y
Reading symbols from /boot/kernel/nullfs.ko.symbols...
location expression too complex...done.

(kgdb) b nullfs_mount
Cannot access memory at address 0x81c14540
```

As one can see from the output of 'nm' and 'kldstat' above, the addresses are indeed proper.

I even tried setting a "hardware breakpoint" at the above address:


```
(kgdb) hbreak *0x81c14540
Hardware assisted breakpoint 1 at 0x81c14540: file
/usr/src/sys/modules/nullfs/../../fs/nullfs/null_vfsops.c, line 74.

(kgdb) c
Continuing.
Warning:
Cannot insert breakpoint 1.
Error accessing memory address 0x81c14540: Input/output error.
```

This time however although the breakpoint is registered, it never gets inserted. On searching for this error on Linux, it appears that this is taken care of by turning off CONFIG_DEBUG_RODATA as part of the kernel config (which as per this link appears to be some sort of a protection mechanism which detects when the text section of the kernel is being overwritten for some reason). This helps with the setting of software breakpoints which would otherwise be not set. I do not know if this is the reason here as well.

Secondly I'd like to know that although the actual addresses on the target are in above 0xffffffff00000000, the debugger merely reports the lower 8 bits. IS it because it is understood/assumed?

Keen to hear from you folks


----------

