jmb
/
hardened_malloc
mirror of https://github.com/GrapheneOS/hardened_malloc.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Fix a couple of mundane typo in the readme

pull/166/head
jvoisin 2022-01-02 13:51:25 +01:00 committed by Daniel Micay
parent 3878f4a5f4
commit 2d56c1de01
1 changed files with 5 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
README.md
View File

@ -100,7 +100,7 @@ executables using glibc or musl:
./preload.sh krita --new-image RGBA,U8,500,500 ./preload.sh krita --new-image RGBA,U8,500,500
It can be necessary to substantially increase the `vm.max_map_count` sysctl to It can be necessary to substantially increase the `vm.max_map_count` sysctl to
accomodate the large number of mappings caused by guard slabs and large accommodate the large number of mappings caused by guard slabs and large
allocation guard regions. The number of mappings can also be drastically allocation guard regions. The number of mappings can also be drastically
reduced via a significant increase to `CONFIG_GUARD_SLABS_INTERVAL` but the reduced via a significant increase to `CONFIG_GUARD_SLABS_INTERVAL` but the
feature has a low performance and memory usage cost so that isn't recommended. feature has a low performance and memory usage cost so that isn't recommended.
@ -138,7 +138,7 @@ between performance and security. However, this reduces security for threat
models where persistent state is untrusted, i.e. verified boot and attestation models where persistent state is untrusted, i.e. verified boot and attestation
(see the [attestation sister project](https://attestation.app/about)). (see the [attestation sister project](https://attestation.app/about)).
Make sure to raise `vm.max_map_count` substantially too to accomodate the very Make sure to raise `vm.max_map_count` substantially too to accommodate the very
large number of guard pages created by hardened\_malloc. This can be done in 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 `init.rc` (`system/core/rootdir/init.rc`) near the other virtual memory
configuration: configuration:
@ -169,7 +169,7 @@ generally not a recommended approach for production usage. The recommendation
is to enable it globally and make exceptions for performance critical cases by is to enable it globally and make exceptions for performance critical cases by
running the application in a container / namespace without it enabled. running the application in a container / namespace without it enabled.
Make sure to raise `vm.max_map_count` substantially too to accomodate the very Make sure to raise `vm.max_map_count` substantially too to accommodate the very
large number of guard pages created by hardened\_malloc. As an example, in large number of guard pages created by hardened\_malloc. As an example, in
`/etc/sysctl.d/hardened_malloc.conf`: `/etc/sysctl.d/hardened_malloc.conf`:
@ -494,7 +494,7 @@ ChaCha8 is a great fit because it's extremely fast across platforms without
relying on hardware support or complex platform-specific code. The security relying on hardware support or complex platform-specific code. The security
margins of ChaCha20 would be completely overkill for the use case. Using margins of ChaCha20 would be completely overkill for the use case. Using
ChaCha8 avoids needing to resort to a non-cryptographically secure PRNG or ChaCha8 avoids needing to resort to a non-cryptographically secure PRNG or
something without a lot of scrunity. The current implementation is simply the something without a lot of scrutiny. The current implementation is simply the
reference implementation of ChaCha8 converted into a pure keystream by ripping reference implementation of ChaCha8 converted into a pure keystream by ripping
out the XOR of the message into the keystream. out the XOR of the message into the keystream.
@ -779,7 +779,7 @@ would be incremented to 5 if one of the adjacent tags was 4):
| 3 | 4 | 15 | 7 | 14 | 15 | | 3 | 4 | 15 | 7 | 14 | 15 |
The last slot is randomly chosen for the next alocation, and is assigned the The last slot is randomly chosen for the next allocation, and is assigned the
random value 14. However, it's placed next to an allocation with the tag 14 so random value 14. However, it's placed next to an allocation with the tag 14 so
the tag is incremented and wraps around to 0: the tag is incremented and wraps around to 0: