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.
1
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
I haven't looked into it yet but some of these many apps I use for testing might have some weird runtime or data structure abusing those bits for storing tags. One thing that really annoyed me is what Go does with the brk heap because I want to have that awful thing disabled.
You can see from the configuration in github.com/GrapheneOS/har that I'm not currently using arenas on GrapheneOS and size class regions are set to 1GiB of usable space (they end up 2x as large for guards) which isn't very future proof. Half that space gets used by guard slabs too.
1
I want to make it so it makes a random choice between inserting 1 or 2 guard slabs instead of only using 1 guard slab between each slab. That's going to further reduce the usable space. I'm already needing to make many compromises based on address space size. Can't do everything.
1
Show replies