5 ms·
I believe I should have couched that statement with a "for most everyone else" :) The PPL is a strong mitigation, I agree, but it is definitely one that is rea
by Sirened 4y ago
I believe I should have couched that statement with a "for most everyone else" :)
The PPL is a strong mitigation, I agree, but it is definitely one that is really only supported through their ability to ship custom hardware. Pulling off a PPL-like thing using MPK or a hypervisor is technically possible but in practice no real platform other than Apple is actually able to enforce memory mappings on all devices on an SoC and so anything you dream up to protect page tables is as durable as a wet paper bag since there's usually a half dozen other chips that will hapilly DMA any and all parts of physical memory for you. I dream of a day where we have an SMMU in front of every single device on a regular smartphone SoC (or, hell, even a PC platform), but that day has not yet come and I'm not really holding my breath either. As such, nobody else can actually meaningfully guarantees kernel code integrity under kernel R/W and so even if they had a perfect PAC implementation (which, as I'm sure you know, is incredibly difficult), you could just corrupt the backing code pages and sidestep it.
- saagarjha 4y agoRight, iOS definitely has a different threat model which requires (and takes advantage of) Apple's ability to make custom hardware. In this case, though, OpenBSD is looking to protect userspace, and they could provide guarantees for that (iOS does this via codesigning, but you could also just force security-sensitive programs to stop using dlopen).