We may want to fold this into `sodium_mprotect_*()` instead of
exposing these functions.
The drawback is that a transition from PROT_NONE to PROT_READ
(or the other way round) would need an intermediary state in PROT_WRITE
for shielding/unshielding.
Shielding is also not thread-safe, while the `mprotect_*()` functions
are, and adding locks would make things more complicated than they
probably should.
In the test suite, a significant amount of time is spent in memory
allocations. A memory pool helps achieve more relevant results with
less iterations.
Tools such as ASAN may trap violations instead of our handlers,
making the sodium_utils{2,3} test fail.
This has been documented for a long time, but it's probably better
to detect this and ignore tests depending on working signal handlers.
ptr = sodium_malloc(size) returns a pointer from which exactly "size" bytes
can be accessed.
ptr = sodium_allocarray(count, size) allocates enough storage space for
"count" pointers or scalars of unit size "size".
In both cases, the region is immediately followed by a guard page.
As a result, any attempt to access a memory location after ptr[size - 1] will
immediately trigger a segmentation fault.
The allocated region is mlock()ed and filled with 0xd0 bytes.
A read-only page with the size, a guard page, as well as a canary are
placed before the returned pointer.
The canary is checked by sodium_free(); as a result, altering data right
before ptr is likely to cause sodium_free() to kill the process.
sodium_free() munlock()s the region and fills it with zeros before
actually calling free().
sodium_mprotect_noaccess(), sodium_mprotect_readonly() and
sodium_mprotect_readwrite() can be used to change the protection on the set
of allocated pages.
Reverting the protection to read+write is not required before calling
sodium_free().
