While we are not a supported system, I would also note that I work on a project which *does* expect `atexit` to work properly, but does not have a working anonymous mmap system due to how resource management works for us.

If ASLR is enabled, that should already mitigate the ability of an attacker to write to this location. While placing these in anonymous pages would be a further defense against cases where a pointer is leaked *and* an arbitrary overwrite is present, this would be an argument for a more complete form of randomization (see also pagerando, https://lists.llvm.org/pipermail/llvm-dev/2017-June/113794.html ) rather than trying to randomize the location of individual chunks of sensitive data.

On Tue, Dec 1, 2020 at 5:37 PM Rich Felker <dalias@libc.org> wrote:
On Tue, Dec 01, 2020 at 05:55:39PM -0700, Ariadne Conill wrote:
> previously, the first atexit list block was stored in BSS, which means an
> attacker could potentially ascertain its location and modify it, allowing
> for its abuse as a code execution mechanism.
>
> by moving the atexit list into a series of anonymous mmaped pages, we can
> use mprotect to protect the atexit lists by keeping them readonly when they
> are not being mutated by the __cxa_atexit() function.

This is a non-starter. atexit is specifically required by the standard
to succeed when called no more than 32 times, which is why we have 32
built-in slots that always exist. If you really want to pursue
something here it should probably just be protecting the pointers with
some secret...

Rich