Re: "Address Randomization Tribulations"

In: s/Linux

I was completery right.

Tried with gdb (yuck), after `set disable-randomization off`, to turn randomization on, because gdb turns randomization off by default (wasting a bunch of my time, but kind of almost doesn't make no sense, pun intended).

(gdb) info proc mappings
process 144876
Mapped address spaces:

        Start Addr   End Addr       Size     Offset  Perms   objfile
         0x8048000  0x804a000     0x2000        0x0  rwxp   /home/stack/src/nForth/nforth
         0x87df000  0xa049000  0x186a000        0x0  rwxp   [heap]
        0xf7f75000 0xf7f79000     0x4000        0x0  r--p   [vvar]
        0xf7f79000 0xf7f7b000     0x2000        0x0  r-xp   [vdso]
        0xffc4e000 0xffc6f000    0x21000        0x0  rwxp   [stack]
(gdb)

So, nforth loads at 0x0804800-0x0804A00, but when heap is expanded up, it starts at 0x087DF000 and goes to 0x0A04900. So the memory space is not contiguous, and the entire idea of sysbreak is bullshit, in this particular case.

🚀 stack [OP]

2023-09-03 · 3 years ago

🌒 s/Linux

🚀 stack:

Address Randomization Tribulations — So, I have a tiny 32-bit application (a Forth) taking up about 4K, written in fasm. Pure minimalism, including an iffy elf header that fasm creates, with a fixed load address. More on that later. It's been unstable, and I tracked the instability down to the initial memory allocation. Right at the start I add my desired memory size to the code base (the top label in asm code), and invoke `brk` system call. This worked as long as I allocated a largish...

💬 1 comment · 2023-09-02 · 3 years ago