macOS arm64 support

(generic issue to track macOS arm64 support)
It's unclear at the moment what macOS x86 (Intel) does at the moment regarding some OS things like page sizes.

Output of clang -v:

june@MacBook hardened_malloc % clang -v
Apple clang version 13.0.0 (clang-1300.0.29.30)
Target: arm64-apple-darwin21.3.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin

Apple Clang does not support -march=native so users need to set CONFIG_NATIVE to false.

clang: error: the clang compiler does not support '-march=native'

Apple Clang doesn't support -fstack-clash-protection either. Requires editing the Makefile and removing it.

clang: error: argument unused during compilation: '-fstack-clash-protection' [-Werror,-Wunused-command-line-argument]

Apple Clang doesn't support -Wcast-align=strict, but supports -Wcast-align by itself? Also requires removing it.

error: unknown warning option '-Wcast-align=strict'; did you mean '-Wcast-align'? [-Werror,-Wunknown-warning-option]

These allow you to get past compiler argument errors.

[thestinger]

The safe_flag check is meant to deal with that. You should figure out why that's not working.

The issue with -fstack-clash-protection is that it's not implemented on arm64 yet.

macOS does not seem to have threads.h anywhere which is used in h_malloc.c. Nothing is provided by Xcode or Xcode Command Line utilities other than a threads.h file for libxml and is not usable here when included.

The only closest alternative is pthread.h.

threads.h by libxml:

/**
 * Summary: interfaces for thread handling
 * Description: set of generic threading related routines
 *              should work with pthreads, Windows native or TLS threads
 *
 * Copy: See Copyright for the status of this software.
 *
 * Author: Daniel Veillard
 */

[thestinger]

hardened_malloc only uses threads.h for thread_local. You can refer to it as _Thread_local instead if that's missing. It's just annoying.

sys/prctl.h also does not exist in macOS. The include was removed and seems to not complain about anything, but may need to be looked into in case it breaks on other OS's.

Apple LLVM linker does not support ANY -z arguments. All -z arguments had to be removed from LDFLAGS in the Makefile.

LDFLAGS := $(LDFLAGS) -Wl

The linker is also trying to link to a shared GCC lib.
ld: library not found for -lgcc_s
Had to drop -lgcc_s from the Makefile's LDLIBS (https://github.com/GrapheneOS/hardened_malloc/blob/main/Makefile#L40-L47)

Apple arm64 also uses 16k pages as documented here which is very likely to be too small: https://developer.apple.com/library/archive/documentation/Performance/Conceptual/ManagingMemory/Articles/AboutMemory.html

In OS X and in earlier versions of iOS, the size of a page is 4 kilobytes. In later versions of iOS, A7- and A8-based systems expose 16-kilobyte pages to the 64-bit userspace backed by 4-kilobyte physical pages, while A9 systems expose 16-kilobyte pages backed by 16-kilobyte physical pages

strcat: will need to totally redo the slot counts / slab sizes
strcat: for 16k
strcat: so atm
strcat: 16 byte allocations go into 4k page
strcat: 256 slots
strcat: if pages are 16k then there are 4x as many
strcat: there isn't enough room in the bitmap atm
strcat: 256 is max # of bits
strcat: it would need a larger bitmap and that would be a fair bit less efficient too
strcat: it gets to the point where it borderline dserves a multi-layer bitmap (2 layer)

That issue will be tackled later down the road. Focus is to get the library to compile and the tests to compile. Then refine everything and make sure stuff still works for other OS's.

Some changes had to be made to simple-memory-corruption as well.

The main development is currently done by @iraizo and is published here: https://github.com/iraizo/hardened_malloc/tree/osx-support

These changes are not final, heavily a WIP, and the changes made were just to compile and produce a library rather than based on accuracy or testing.

SMC tests after their changes: https://gist.github.com/Zanthed/1bbe99243db0e4348938294841bf9e9a

[jvoisin]

#192 is a first step in this direction.

[iraizo]

Looks good.