emo/hardened_malloc
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

use round-robin assignment to arenas

Browse Source 
The initial implementation was a temporary hack rather than a serious
implementation of random arena selection. It may still make sense to
offer it but it should be implemented via the CSPRNG instead of this
silly hack. It would also make sense to offer dynamic load balancing,
particularly with sched_getcpu().

This results in a much more predictable spread across arenas. This is
one place where randomization probably isn't a great idea because it
makes the benefits of arenas unpredictable in programs not creating a
massive number of threads. The security benefits of randomization for
this are also quite small. It's not certain that randomization is even a
net win for security since it's not random enough and can result in a
more interesting mix of threads in the same arena for an attacker if
they're able to attempt multiple attacks.
This commit is contained in:
Daniel Micay 2019-04-09 16:36:01 -04:00
parent 9a0de626fc
commit d5c1bca915
1 changed files with 2 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
h_malloc.c
View File

@ -56,6 +56,7 @@ static_assert(N_ARENA <= 4, "currently only support up to 4 arenas (as an initia
#if N_ARENA > 1
__attribute__((tls_model("initial-exec")))
static thread_local unsigned thread_arena = N_ARENA;
static _Atomic unsigned thread_arena_counter = 0;
#else
static const unsigned thread_arena = 0;
#endif
@ -469,7 +470,7 @@ static inline void *allocate_small(size_t requested_size) {
#if N_ARENA > 1
if (unlikely(thread_arena == N_ARENA)) {
thread_arena = hash_page(&thread_arena) % N_ARENA;
thread_arena = thread_arena_counter++ % N_ARENA;
}
#endif