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.
If <min-reserved-size> is less than <max-heap-size>, the code will
still assume that only <min-reserved-size> bytes are accessible and
will trap even if the runtime could allocate more..
So, `max` should always be <= `min`. Naming options is hard.
However:
- wasmer seems to have issues with signals, causing some tests to fail
- lucet's --dir option doesn't seem to work with relative paths
These are temporary limitations, that are likely to be fixed soon.
Justifications:
- crypto_(auth|hash|generichash|onetimeauth|shorthash)*:
it's legal to hash or HMAC a 0-length message
- crypto_box*: it's legal to encrypt a 0-length message
- crypto_sign*: it's legal to sign a 0-length message
- utils:
comparing two 0-length byte arrays is legal
memzero on a 0-length byte array is a no-op
converting an empty hex string to binary results in an empty binary string
converting an empty binary string to hex results in an empty hex string
converting an empty b64 string to binary results in an empty binary string
converting an empty binary string to b64 results in an empty b64 string
sodium_add / sodium_sub on zero-length arrays is a no-op
For the functions declared in utils.h, I moved the logic into private functions that
have the __attribute__ ((nonnull)) check, but they are only called when the
corresponding length argument is non-0. I didn't do this for the hash/box/sign
functions since it would have been a lot more work and quite a large refactor.
