Fix coredump_phnum test with ASLR enabled by default

[emaste]

Summary

coredump_phnum test tries to generate a core file with many PT_LOAD segments. Previously it called mmap() in a loop with alternating protections, relying on each mapping following the previous. This resulted in a core file with many page-sized PT_LOAD segments. With ASLR on we no longer have this property of each mmap() following the previous.

Instead, perform a single allocation, and then use mprotect() to set alternating pages to PROT_READ.

PR: 259970

[kib]

I am not sure that this change makes code in any way better than previous version. Now it depends on internals of malloc(3) that are probably the implementation details.
I would preallocate large region with MAP_ANON, and then change the protection of each second page as you do. Or preallocate large region with MAP_GUARD, and then allocate pages with MAP_FIXED/incompatible protections.

BTW, what is the condition that fails to hold with the aslr enabled? Old code, as is, still creates many page-sized mappings, which are not coalsesced.

[emaste]

allocate MAP_ANON region, per kib

[emaste]

BTW, what is the condition that fails to hold with the aslr enabled?

The test tries to create (a bit over) 65536 LOAD segments, added here:

commit e8e39fc29e6fc7df03edc6bb80444f22796a49e7
Author: Conrad Meyer <[e-mail]>
Date:   Tue Nov 1 19:18:16 2016 +0000

    Add test case for >65535 segment coredumps
    
    A long-belated follow-up to r303099.
    
    With feedback from:     jmmv, ngie
    Sponsored by:   Dell EMC Isilon
    Differential Revision:  https://reviews.freebsd.org/D7264

Notes:
    svn path=/head/; revision=308177

Here is a testrun log: https://ci.freebsd.org/job/FreeBSD-main-amd64-test/19867/testReport/junit/sys.kern/coredump_phnum_test/coredump_phnum/

Number of program headers: 17

So it seems there is coalescing happening?

[kib]

I am somewhat surprised that coalescing worked that good,

tests/sys/kern/coredump_phnum_helper.c

57–59

Since you are mprotect'ing at the page (i+1), shouldn't loop use i < pages - 1 as the stop condition? For me, it looks like you are changing protection of one page after the mmaped region.

Or change mmap to allocate pages + 1 pages.

[emaste]

avoid + 1 issue per kib

+/- one page at the boundary doesn't matter