Page MenuHomeFreeBSD

Fix coredump_phnum test with ASLR enabled by default
ClosedPublic

Authored by emaste on Sun, Nov 21, 4:40 PM.

Details

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

Diff Detail

Repository
R10 FreeBSD src repository
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

emaste created this revision.

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.

allocate MAP_ANON region, per kib

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 <cem@FreeBSD.org>
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?

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.

avoid + 1 issue per kib

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

This revision is now accepted and ready to land.Sun, Nov 21, 5:51 PM