Finally dropping the workaround for the Linux kernel Memory Protection Keys bug discovered during hardened_malloc development:
github.com/GrapheneOS/har
This could be considered a security bug but no CVE was obtained so many Linux distributions still haven't applied this patch.
Conversation
Replying to
Dave Hansen quickly created a patch after I reported it, but it took a long time to land. IIRC, it missed a few major kernel releases before it finally landed. It got applied in a few of the longterm kernel branches, but some Linux distributions will only apply fixes with a CVE.
1
2
Anyone deploying MPK across distributions will be running into this problem for years to come! Not interested in workarounds for legacy issues in hardened_malloc. MPK was also a disappointment due to the lackluster performance. Far faster than using mprotect but still very slow.
1
It provides per-thread memory protections in userspace and is faster than mprotect, but not nearly as fast as it was supposed to be. It causes a massive pipeline stall resulting in a comparable cost to acquiring and releasing an uncontended lock. It might have been faster before.
1
It's quite possible that MPK performance was a casualty of CPU side channel mitigations. It would be interesting to measure performance across a variety of CPUs including the earliest ones with support for it using the earliest available microcode without all those mitigations.
1
CONFIG_SEAL_METADATA is the only hardened_malloc security feature not enabled by default. It has very low value due to metadata being fully out-of-line in a reserved address space region. Hardware memory tagging like SPARC ADI and the upcoming ARMv8.5 MTE is FAR more compelling.
1