From 2d56c1de01ac9ca13fb5aa09b9ce2b8313b17413 Mon Sep 17 00:00:00 2001 From: jvoisin Date: Sun, 2 Jan 2022 13:51:25 +0100 Subject: [PATCH] Fix a couple of mundane typo in the readme --- README.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/README.md b/README.md index 459760e..81cc892 100644 --- a/README.md +++ b/README.md @@ -100,7 +100,7 @@ executables using glibc or musl: ./preload.sh krita --new-image RGBA,U8,500,500 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 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. @@ -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 (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 `init.rc` (`system/core/rootdir/init.rc`) near the other virtual memory 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 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 `/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 margins of ChaCha20 would be completely overkill for the use case. Using 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 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 | -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 the tag is incremented and wraps around to 0: