Consider a loop that calls malloc(16) and free(16) repeatedly. Normally the allocations will always be in cache. But in an allocator that never reuses memory every new page will miss.
Conversation
Indeed this example will be slow, but who calls malloc/free in a hot loop?
There's also a much more granular safety story - you could allow some of your trusted dependencies to be compiled in ReleaseFast mode but most of your application in ReleaseSafe.
4
3
i was interested in giving this a try, so i tried the following code but it seems to do the UAF? i didn't configure the allocator at all but from what i read in the docs, it doesn't seem to be necessary? i just did "zig run test.zig"
2
this is my output. are you on Windows? safety checking is still TODO on that platform
1
1
i'm using linux (zig 0.7.1 from the arch linux repo to be precise) 😕
1
1
huh. I'd like to try to reproduce these results. mind sharing an strace?
1
1
gist.github.com/saleemrashid/6 🙏
mmap hint looks wrong? (also that's a surprising number of write syscalls for one std.debug.print 👀)
1
2
oh! it is something related to the linux-hardened kernel github.com/anthraxx/linux (it does the right thing on the non-hardened one), might know why
1
It primarily just fixes x86 vdso randomization and uses the maximum values for ASLR entropy configuration by default which are already configurable via sysctl.
1
I'd strongly recommend measuring the size of the address space and reserving a huge portion as a massive PROT_NONE mapping rather than using hints though. mmap hints aren't respected everywhere and you can end up with other mappings getting in the way and screwing up the hints.
Basically, make a massive PROT_NONE mapping and then you allocate with mprotect to PROT_READ|PROT_WRITE and free by using MAP_FIXED mmap to replace a section with a new fresh PROT_NONE region. It prevents anything else from getting that via mmap outside of your own mmap usage.
2
2
9
Show replies
The cost of making a 64TiB PROT_NONE mapping is the same as making a 4k PROT_NONE mapping. It's how hardened_malloc handles slab allocations. Works fine with non-overcommit since a fresh PROT_NONE mapping isn't accountable memory. RLIMIT_AS is the only issue and that's misguided.
1
Can also free in 2 system calls with madvise MADV_DONTNEED and then mprotect back to PROT_NONE but I expect the kernel is too stupid to realize that shouldn't count towards your accountable memory limit for non-overcommit and a single MAP_FIXED mmap system call is faster anyway.