Conversation

I'm working on integrating Memory Protection Keys (lwn.net/Articles/64379) into my hardened allocator for protecting the metadata. Unfortunately, I can't verify it works and has low enough overhead until I get access to a Skylake-SP CPU so it will be stuck in a separate branch.
2
7
It's very easy to integrate since there are dedicated memory regions for metadata isolated from everything else. MPK allows toggling access to memory regions per-thread via a bit in a register, so the allocator can toggle metadata access on entry/exit.
Quote Tweet
Finished up the unified metadata region for my hardened allocator: github.com/AndroidHardeni It avoids reusing metadata address space for other purposes and vice versa along with having high entropy random guard regions. It will use Memory Protection Keys or memory tagging too.
Show this thread
1
2
Replying to
It wouldn't be usable for this if it wasn't a register controlled by userspace. The whole point for this is that it allows for efficient transitions. I could be doing the same thing with mprotect but it would several orders of magnitude too slow and would serialize it all too.
1
1
Replying to and
It's not a disadvantage but the rather the reason it can be used. If the attacker has enough control over the program's execution to disable this, it's already far beyond the point that memory protecting the allocator metadata can serve any purpose anymore. It's similar to SMAP.
1
1
Replying to and
A proper implementation of the feature would also only use inline writes of the register. The glibc implementation is low quality and doesn't consider security, but it doesn't matter for this use case. It also isn't intended that it's used without other important libc hardening.
1
1