this is what it looks like for me
Conversation
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
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
I mean, if this is linux then you could just skip some steps by doing the massive mmap, make it all rw, and then only touch a page when you want the kernel to allocate a page for it. There will be a bit of read ahead but Linux’s allocation uses an “optimistic” strategy.
1
It won't work well in the default heuristic overcommit mode which gives you the worst of both worlds. It only works properly in the full overcommit mode. Linux has support for a memory accounting mode too, and it doesn't work for that, since rw anon memory is accountable.
2
1
1
Making a many terabyte rw mapping will work on Android, but it won't work as expected on typical desktop/server Linux distributions because they use the default nonsense heuristic overcommit mode. Also don't think breaking compatibility with memory accounting mode is a good idea.
The mlockall issue is fixable for PROT_NONE mappings and is essentially a Linux kernel bug which exists right now. If it's not PROT_NONE, then the bad interaction isn't fixable.
Plan on dealing with it at some point upstream for hardened_malloc (github.com/GrapheneOS/har).
