The implementation of arc4random_buf differs from its documentation. It
is documented as "always successful, and no return value is reserved to
indicate an error" for the sake of FreeBSD compatibility [1]. However,
the actual implementation on macOS invokes function "ccrng_generate" [2]
without validating the error cases. It might fail silently[3], which leads
to unexpected source of entropy.
The original arc4random used the RC4 a.k.a. ARC4 algorithm, and ChaCha20
based implementation was introduced in FreeBSD 12.0. Since macOS 10.12,
it was replaced with the NIST-approved AES cipher, and it may be replaced
again in the future as cryptographic techniques advance. Therefore, we
should not assume that arc4random never fails.
On the contrary, CCRandomGenerateBytes(), part of Cryptographic Services [4],
returns cryptographically strong random bits with explicit status code.
This patch properly calls CCRandomGenerateBytes() and checks the status.
[1] https://www.freebsd.org/cgi/man.cgi?query=arc4random_buf
[2] https://opensource.apple.com/source/CommonCrypto/CommonCrypto-60178.40.2/lib/CommonRandom.c.auto.html
[3] https://opensource.apple.com/source/Libc/Libc-1439.40.11/gen/FreeBSD/arc4random.c.auto.html
[4] https://developer.apple.com/documentation/security
The standard way of cmake install to a destination folder is the following pattern:
```shell
cd <BUILD_DIR>
cmake <SRC_DIR>
cmake --build <BUILD_DIR>
cmake --install <BUILD_DIR> --prefix <INSTALL_DIR>
```
Right now, the `<INSTALL_DIR>` folder passed in cmake --install command is ignored,
and always installed into `C:/Program Files(x86)/...`, which is the default
`CMAKE_INSTALL_PREFIX` value passed at the `cmake <SRC_DIR>` call.
Thus, it is not possible to install the binaries into different folders
without rerun the cmake/build process.
The important thing here is, the cmake variable `CMAKE_INSTALL_PREFIX`
is supposed to be passed at `cmake --install` time with the `--prefix` argument.
In cmake file, `install` with relative path will use that prefix automaticlly.
And it is the best practice to not include CMAKE_INSTALL_PREFIX
in the `install(... DESTINATION )` argument:
```
In particular, there is no need to make paths absolute by prepending
CMAKE_INSTALL_PREFIX; this prefix is used by default if the DESTINATION is a relative path.
```
referenced from: https://cmake.org/cmake/help/latest/command/install.html
Android's Bionic libc stores the thread ID in TLS slot 1 instead of 0
on 32-bit ARM and AArch64. Slot 0 contains a pointer to the ELF DTV
(Dynamic Thread Vector) instead, which is constant for each loaded DSO.
Because mimalloc uses the thread ID to determine whether operations are
thread-local or cross-thread (atomic), all threads having the same ID
causes internal data structures to get corrupted quickly when multiple
threads are using the allocator:
mimalloc: assertion failed: at "external/mimalloc/src/page.c":563, mi_page_extend_free
assertion: "page->local_free == NULL"
mimalloc: assertion failed: at "external/mimalloc/src/page.c":74, mi_page_is_valid_init
assertion: "page->used <= page->capacity"
mimalloc: assertion failed: at "external/mimalloc/src/page.c":100, mi_page_is_valid_init
assertion: "page->used + free_count == page->capacity"
mimalloc: assertion failed: at "external/mimalloc/src/page.c":74, mi_page_is_valid_init
assertion: "page->used <= page->capacity"
Add support for Android's alternate TLS layout to fix the crashes in
multi-threaded use cases.
Fixes#376.
