←back to thread

Memory Integrity Enforcement

(security.apple.com)
461 points circuit | 1 comments | | HN request time: 0.302s | source
Show context
saurik ◴[] No.45188937[source]
> We believe memory safety protections need to be strictly synchronous, on by default, and working continuously.

FWIW, I presume this is "from experience"--rather than, from first principles, which is how it comes off--as this is NOT how their early kernel memory protections worked ;P. In 2015, with iOS 9, Apple released Kernel Patch Protection (KPP), which would verify that the kernel hadn't been modified asynchronously--and not even all that often, as I presume it was an expensive check--and panic if it detected corruption.

https://raw.githubusercontent.com/jakeajames/rootlessJB/mast...

> First let’s consider our worst enemy since iOS 9: KPP (Kernel Patch Protection). KPP keeps checking the kernel for changes every few minutes, when device isn’t busy.

> That “check every now and then” thing doesn’t sound too good for a security measure, and in fact a full bypass was released by Luca Todesco and it involves a design flaw. KPP does not prevent kernel patching; it just keeps checking for it and if one is caught, panics the kernel. However, since we can still patch, that opens up an opportunity for race conditions. If we do things fast enough and then revert, KPP won’t know anything ;)

replies(3): >>45190808 #>>45190958 #>>45191311 #
1. MBCook ◴[] No.45190958[source]
> FWIW, I presume this is "from experience"--rather than, from first principles, which is how it comes off

I interpreted that as what they came up with when first looking at/starting to implement MTE, not their plan since $longTimeAgo.

Apple has certainly gotten better about security, and I suspect things like what you listed are a big part of why. They were clearly forced to learn a lot by jailbreakers.