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.
Conversation
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.
2
3
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.
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.