47-bit address space size on x86_64 and arm64 is already cramped with how github.com/GrapheneOS/har uses it and features like github.com/GrapheneOS/har are going to make that a bigger issue. Arenas have a similar impact. I'd love having 5 level page tables available to be honest.
Conversation
Memory tagging in ARMv8.5 will be really nice, but the tags are only 4-bit so that evaporates pretty quickly. I think the way to go will be reserving a single tag used internally for the metadata, padding and free allocations. Same reservation can be reused outside malloc too.
1
2
It turns out that I can't even use 4-level pages tables in practice for arm64 due to buggy applications, drivers, etc. It's close to working but there are some showstoppers with hard-wired assumptions. Maybe it can be be worked around but I don't enjoy needing to fix everything.
1
2
Replying to
Yeah, I was really annoyed by this. I could probably work around the Adreno issue or report it and get them to fix it within a few months but I didn't anticipate the level of breakage there would be from enabling usage of more address space. It's pretty frustrating for me.
hardened_malloc reserves dedicated regions for each slab size class and their metadata. It never reuses or obtains more address space by design, for security reasons. There are 4 size classes per doubling in size (github.com/GrapheneOS/har) so there are a lot. Arenas multiply this.
1
1
So if I want to use 8 arenas, that means reserving 8x as much address space due to how it works. If the address space was 56-bit, running out wouldn't be a concern, but 48-bit is not really that much especially with other features also heavily using it like Clang cross-DSO CFI.
1
1
Show replies