Interesting to see this being supported. I remember OpenBSD jumping through insane hoops to get W^X to work on x86-32 (it was possible, but only by composing page and segment protections) and this looks like a continuation of that awesome mindset (using MPK to fudge the permission). The timing is a bit odd though, because I thought people were starting to deemphasise XOM in other places because side channels made it fairly easy to leak the contents, unless you’re talking about JIT’d code with a JIT that is also doing some randomisation).
I guess once mmap supports PROT_EXEC without PROT_READ userspace things can start doing interesting things with it. OpenBSD’s W^X was the reason that a lot of JITs started properly supporting separate mappings for executable and writeable memory (if I remember correctly, some OpenBSD folks upstreamed the emacs changes), long before anyone else cared and now W^X is just expected as a security baseline.
Maybe some people, but not all …and I’m guessing if people have given up it’s because of the archaic lack of support in the x86 mmu.
It’s going to be fun to see how this evolves for amd64 given the pivoting of userland protection keys to something it wasn’t really designed for by Intel. I proposed the pmap hack initially to Theo in a proof of concept after I doubted it would be worth it. Then I convinced myself maybe there was something here after all.
Tangentially, what I’m surprised about is how Intel never put any hooks into VMX related to PKRU. I haven’t checked AMD’s SVM yet, but seems like protection keys are sort of a half-hearted effort by Intel?
X-only is interesting because you can hide secrets in code; those side channels are only significant when an attacker has arbitrary code exec in some sort of sandbox, but if they have only a read primitive (eg buffer overflow because you were stupid and parsed some net stuff in c) it’s a meaningful protection. Sadly not yet really widespread enough to rely on, but maybe eventually…
There are a lot of ways to exploit a side channel that don’t rely on ACE. Things like netspectre are great examples but often there are other gadgets that can be triggered with purely data oriented attacks.
Interesting to see this being supported. I remember OpenBSD jumping through insane hoops to get W^X to work on x86-32 (it was possible, but only by composing page and segment protections) and this looks like a continuation of that awesome mindset (using MPK to fudge the permission). The timing is a bit odd though, because I thought people were starting to deemphasise XOM in other places because side channels made it fairly easy to leak the contents, unless you’re talking about JIT’d code with a JIT that is also doing some randomisation).
I guess once
mmapsupportsPROT_EXECwithoutPROT_READuserspace things can start doing interesting things with it. OpenBSD’s W^X was the reason that a lot of JITs started properly supporting separate mappings for executable and writeable memory (if I remember correctly, some OpenBSD folks upstreamed the emacs changes), long before anyone else cared and now W^X is just expected as a security baseline.Maybe some people, but not all …and I’m guessing if people have given up it’s because of the archaic lack of support in the x86 mmu.
It’s going to be fun to see how this evolves for amd64 given the pivoting of userland protection keys to something it wasn’t really designed for by Intel. I proposed the pmap hack initially to Theo in a proof of concept after I doubted it would be worth it. Then I convinced myself maybe there was something here after all.
Tangentially, what I’m surprised about is how Intel never put any hooks into VMX related to PKRU. I haven’t checked AMD’s SVM yet, but seems like protection keys are sort of a half-hearted effort by Intel?
X-only is interesting because you can hide secrets in code; those side channels are only significant when an attacker has arbitrary code exec in some sort of sandbox, but if they have only a read primitive (eg buffer overflow because you were stupid and parsed some net stuff in c) it’s a meaningful protection. Sadly not yet really widespread enough to rely on, but maybe eventually…
There are a lot of ways to exploit a side channel that don’t rely on ACE. Things like netspectre are great examples but often there are other gadgets that can be triggered with purely data oriented attacks.