On Thu, 7 Nov 2019, Theo Buehler wrote:
> I was trying to debug a WIP port, so I compiled it with '-g -O0' on my
> amd64 laptop. When trying to execute the binary, I got
>
> $ ./lean
> ksh: ./lean: Cannot allocate memory
>
> mpi was able to pinpoint this to the following check in exec_elf.c:
>
> 699 case PT_OPENBSD_RANDOMIZE:
> 700 if (ph[i].p_memsz > randomizequota) {
> 701 error = ENOMEM;
> 702 goto bad;
> 703 }
>
> so we got ENOMEM because some of the the program headers are too large.
...
> OPENBSD_RANDOM 0x0000000001185000 0x0000000001185000 0x0000000001185000
> 0x000000000012c1a0 0x000000000012c1a0 RW 8
Right: we limit random data section to 0x100000 in size. So, what's
making the section so big on this binary? There's a bug in how the
compiler generates retguard symbols** that can cause it to take more than
expected, but even for the kernel it didn't blow it up that large.
** we have a fix, we just need to adjust kernel ld scripts to work with
it...
> I'm not sure if this a bug or a feature, but if it happens to be a bug, the
> binary (compiled with -current) and the ports makefile available under
>
> cvs:~tb:lean/{lean,lean.tgz}
Unfortunately, the binary is stripped so there are no symbols for the
.openbsd.randomdata segment so we can't confirm the cause.
