mirror of
https://github.com/GrapheneOS/hardened_malloc.git
synced 2024-12-20 05:14:28 -05:00
OS integration guide
This commit is contained in:
parent
d80919fa1e
commit
3ed6e546c8
53
README.md
53
README.md
@ -79,6 +79,59 @@ this allocator offers across different size classes. The intention is that this
|
|||||||
will be offered as part of hardened variants of the Bionic and musl C standard
|
will be offered as part of hardened variants of the Bionic and musl C standard
|
||||||
libraries.
|
libraries.
|
||||||
|
|
||||||
|
# OS integration
|
||||||
|
|
||||||
|
## Android-based operating systems
|
||||||
|
|
||||||
|
On GrapheneOS, hardened\_malloc is integrated into the standard C library as
|
||||||
|
the standard malloc implementation. Other Android-based operating systems can
|
||||||
|
reuse the integration code to provide it. If desired, jemalloc can be left as
|
||||||
|
a runtime configuration option by only conditionally using hardened\_malloc to
|
||||||
|
give users the choice between performance and security. However, this reduces
|
||||||
|
security for threat models where persistent state is untrusted, i.e. verified
|
||||||
|
boot and attestation (see the [attestation sister
|
||||||
|
project](https://attestation.app/about)).
|
||||||
|
|
||||||
|
Make sure to raise `vm.max_map_count` substantially too to accomodate the very
|
||||||
|
large number of guard pages created by hardened\_malloc. This can be done in
|
||||||
|
`init.rc` (`system/core/rootdir/init.rc`) near the other virtual memory
|
||||||
|
configuration:
|
||||||
|
|
||||||
|
write /proc/sys/vm/max_map_count 524240
|
||||||
|
|
||||||
|
This is unnecessary if you set `CONFIG_GUARD_SLABS_INTERVAL` to a very large
|
||||||
|
value in the build configuration.
|
||||||
|
|
||||||
|
## Traditional Linux-based operating systems
|
||||||
|
|
||||||
|
On traditional Linux-based operating systems, hardened\_malloc can either be
|
||||||
|
integrated into the libc implementation as a replacement for the standard
|
||||||
|
malloc implementation or loaded as a dynamic library. Rather rebuilding each
|
||||||
|
executable to be linked against it, it can be added as a preloaded library to
|
||||||
|
`/etc/ld.so.preload`. For example, with `libhardened_malloc.so` installed to
|
||||||
|
`/usr/local/lib/libhardened_malloc.so`, add that full path as a line to the
|
||||||
|
`/etc/ld.so.preload` configuration file:
|
||||||
|
|
||||||
|
/usr/local/lib/libhardened_malloc.so
|
||||||
|
|
||||||
|
The format of this configuration file is a whitespace-separated list, so it's
|
||||||
|
good practice to put each library on a separate line.
|
||||||
|
|
||||||
|
Using the `LD_PRELOAD` environment variable to load it on a case-by-case basis
|
||||||
|
will not work when `AT_SECURE` is set such as with setuid binaries. It's also
|
||||||
|
generally not a recommended approach for production usage. The recommendation
|
||||||
|
is to enable it globally and make exceptions for performance critical cases by
|
||||||
|
running the application in a container / namespace without it enabled.
|
||||||
|
|
||||||
|
Make sure to raise `vm.max_map_count` substantially too to accomodate the very
|
||||||
|
large number of guard pages created by hardened\_malloc. As an example, in
|
||||||
|
`/etc/sysctl.d/hardened_malloc.conf`:
|
||||||
|
|
||||||
|
vm.max_map_count = 524240
|
||||||
|
|
||||||
|
This is unnecessary if you set `CONFIG_GUARD_SLABS_INTERVAL` to a very large
|
||||||
|
value in the build configuration.
|
||||||
|
|
||||||
## Configuration
|
## Configuration
|
||||||
|
|
||||||
You can set some configuration options at compile-time via arguments to the
|
You can set some configuration options at compile-time via arguments to the
|
||||||
|
Loading…
Reference in New Issue
Block a user