grapheneos/hardened_mallocEin gehärteter Allocator, der für moderne Systeme entwickelt wurde. Er ist in Androids Bionic libc integriert und kann extern mit musl und glibc als dynamische Bibliothek für die Verwendung auf anderen Linux-basierten Plattformen genutzt werden. Mit der Zeit wird er mehr Portabilität/Integration gewinnen.
Dies ist ein sicherheitsorientierter Allzweck-Speicherallokator, der die malloc-API zusammen mit verschiedenen Erweiterungen bereitstellt. Er bietet umfangreiche Härtung gegen Schwachstellen durch Heap-Korruption. Das sicherheitsorientierte Design führt zudem zu deutlich weniger Metadaten-Overhead und Speicherverschwendung durch Fragmentierung als ein traditionelleres Allokator-Design. Es zielt auf eine anständige Gesamtleistung ab, mit Fokus auf Langzeit-Performance und Speicherverbrauch statt auf Allokator-Mikrobenchmarks. Es bietet Skalierbarkeit über eine konfigurierbare Anzahl vollständig unabhängiger Arenen, wobei die interne Sperrung innerhalb der Arenen weiter pro Größenklasse aufgeteilt wird.
Dieses Projekt unterstützt derzeit Bionic (Android), musl und glibc. Es könnte in Zukunft andere Nicht-Linux-Betriebssysteme unterstützen. Für Android gibt es eine benutzerdefinierte Integration und weitere Härtungsfunktionen, die künftig auch für musl geplant sind. Die glibc-Unterstützung wird auf das Ersetzen der malloc-Implementierung beschränkt bleiben, da musl eine deutlich robustere und sauberere Basis zum Aufbauen ist und dieselben Anwendungsfälle abdecken kann.
Dieser Allokator ist als Nachfolger einer früheren Implementierung gedacht, die auf einer Erweiterung von OpenBSD malloc mit verschiedenen zusätzlichen Sicherheitsfunktionen basierte. Er baut weiterhin stark auf dem OpenBSD-malloc- Design auf, allerdings nicht auf dem bestehenden Code, abgesehen von der Wiederverwendung der Hash-Tabellen-Implementierung. Die Hauptunterschiede im Design bestehen darin, dass er ausschließlich auf Härtung statt auf das Finden von Fehlern ausgerichtet ist, feinere Größenklassen zusammen mit Slab-Größen jenseits von 4k verwendet, um interne Fragmentierung zu reduzieren, nicht darauf angewiesen ist, dass der Kernel eine feingranulare mmap-Randomisierung bietet, und ausschließlich auf 64-Bit abzielt, um den großen Adressraum aggressiv zu nutzen. Es gibt viele kleinere Unterschiede im Implementierungsansatz. Er integriert die früheren Erweiterungen von OpenBSD malloc, einschließlich des Hinzufügens von Padding zu Allokationen für Canaries (verschieden von den aktuellen OpenBSD-malloc-Canaries), der an das bestehende Löschen beim Freigeben gekoppelten Write-after-free-Erkennung, Warteschlangen neben den bestehenden randomisierten Arrays zur Quarantäne von Allokationen sowie einer ordnungsgemäßen Double-free-Erkennung für in Quarantäne befindliche Allokationen. Die Speicherbereiche pro Größenklasse mit ihren eigenen zufälligen Basen wurden lose von der größen- und typbasierten Partitionierung in PartitionAlloc inspiriert. Die geplanten Änderungen an OpenBSD malloc erwiesen sich als zu umfangreich und invasiv, sodass dieses Projekt als frische Implementierung gestartet wurde, die die Ziele besser erreichen kann. Für 32-Bit kann stattdessen ein Port von OpenBSD malloc mit kleinen Erweiterungen verwendet werden, da dieser Allokator diese Umgebung grundsätzlich nicht unterstützt.
Debian stable (derzeit Debian 13) bestimmt die älteste unterstützte Abhängigkeitsmenge:
Für Android werden die Linux-GKI-Zweige 6.1, 6.6 und 6.12 unterstützt.
Die Verwendung neuerer Releases wird jedoch dringend empfohlen. Ältere Versionen der Abhängigkeiten sind derzeit möglicherweise kompatibel, werden aber nicht getestet und explizit nicht unterstützt.
Für den externen malloc-Ersatz mit musl ist musl 1.1.20 erforderlich. Es wird jedoch in Zukunft eine benutzerdefinierte Integration mit besserer Leistung sowie weitere Härtungsmaßnahmen für die C-Standardbibliotheksimplementierung geben.
Für Android wird nur die aktuelle, aktiv entwickelte Wartungszweig-Generation des Android Open Source Project unterstützt, was derzeit android17-release bedeutet.
Das Skript preload.sh kann zum Testen mit dynamisch gelinkten ausführbaren Dateien verwendet werden, die glibc oder musl nutzen:
./preload.sh krita --new-image RGBA,U8,500,500
Es kann notwendig sein, den Sysctl-Parameter vm.max_map_count erheblich zu erhöhen, um die große Anzahl von Mappings zu bewältigen, die durch Guard-Slabs und große Guard-Regionen für Allokationen verursacht werden. Die Anzahl der Mappings kann auch durch eine deutliche Erhöhung von CONFIG_GUARD_SLABS_INTERVAL drastisch reduziert werden, aber das Feature hat geringe Leistungs- und Speicherverbrauchskosten, sodass dies nicht empfohlen wird.
Es kann eine etwas bessere Leistung bieten, wenn es in die C-Standardbibliothek integriert wird, und es gibt weitere Möglichkeiten für ähnliche Härtung innerhalb von C-Standardbibliotheks- und dynamischen Linker-Implementierungen. Beispielsweise kann eine Bibliotheksregion implementiert werden, um eine ähnliche Isolation für dynamische Bibliotheken zu bieten, wie dieser Allocator sie über verschiedene Größenklassen hinweg bietet. Die Absicht ist, dies als Teil gehärteter Varianten der Bionic- und musl-C-Standardbibliotheken anzubieten.
Es wird eine Sammlung einfacher, automatisierter Tests bereitgestellt, die mit dem make-Befehl wie folgt ausgeführt werden können:
make test
OpenSSH 8.1 oder höher ist erforderlich, um die mprotect-Systemaufrufe PROT_READ|PROT_WRITE im seccomp-bpf-Filter zu erlauben, anstatt den Prozess zu beenden.
Auf GrapheneOS ist hardened_malloc als Standard-malloc-Implementierung in die Standard-C-Bibliothek integriert. Andere Android-basierte Betriebssysteme können den Integrationscode wiederverwenden, um es bereitzustellen. Falls gewünscht, kann jemalloc als Laufzeitkonfigurationsoption beibehalten werden, indem hardened_malloc nur bedingt verwendet wird, um Benutzern die Wahl zwischen Leistung und Sicherheit zu geben. Dies verringert jedoch die Sicherheit für Bedrohungsmodelle, bei denen persistenter Zustand nicht vertrauenswürdig ist, d. h. verifizierter Boot und Attestierung (siehe das Attestierungs-Schwesterprojekt).
Stellen Sie außerdem sicher, dass vm.max_map_count erheblich erhöht wird, um die sehr große Anzahl von Guard-Seiten zu bewältigen, die von hardened_malloc erzeugt werden. Dies kann in init.rc (system/core/rootdir/init.rc) in der Nähe der anderen Konfiguration für virtuellen Speicher erfolgen:
write /proc/sys/vm/max_map_count 1048576
Dies ist nicht erforderlich, wenn Sie CONFIG_GUARD_SLABS_INTERVAL in der Build-Konfiguration auf einen sehr großen Wert setzen.