SEAR and the Apple team does an excellent job of security on iOS, and should be commended greatly on that.
Not only are they willing to develop hardware features and plumb that throughout the entire stack, they're willing to look at ITW exploits and work on ways to mitigate that. PPL was super interesting, they decided it wasn't 100% effective so they ditched it and came up with other thigs.
Apple's vertical makes it 'easy' to do this compared to Android where they have to convince the CPU guys at QC or Mediatek to build a feature, convince the linux kernel to take it, get it in AOSP, get it in upstream LLVM, etc etc.
Pointer authentication codes (PAC) is a good example, Apple said f-it we'll do it ourselves. They maintained a downstream fork of LLVM, and built full support, leveraged in the wild bypasses and fixed those up.
They do that now because they care about your security, but to make it difficult to modify (jailbreak) your own devices to run your own software that is not approved by Apple.
What they do is against your interests, for them to keep the monopoly on the App Store.
And after all that hardcore engineering work is done, iMessage still has code paths leading to dubious code running in the kernel, enabling 0-click exploits to still be a thing.
One of the knock on benefits of this too is increased security across all platforms as long as someone exercises that code path on one of apples new processors with a hardened runtime.
In theory it makes it easier to catch stuff that you can’t simply catch with static analysis and it gives you some level of insight beyond simply crashing.
Google could have added MTE for a couple of years now, but apparently don't want to force it on OEMs as part of their Android certification program, it is the same history as with OS updates.
SEAR and the Apple team does an excellent job of security on iOS, and should be commended greatly on that.
Not only are they willing to develop hardware features and plumb that throughout the entire stack, they're willing to look at ITW exploits and work on ways to mitigate that. PPL was super interesting, they decided it wasn't 100% effective so they ditched it and came up with other thigs.
Apple's vertical makes it 'easy' to do this compared to Android where they have to convince the CPU guys at QC or Mediatek to build a feature, convince the linux kernel to take it, get it in AOSP, get it in upstream LLVM, etc etc.
Pointer authentication codes (PAC) is a good example, Apple said f-it we'll do it ourselves. They maintained a downstream fork of LLVM, and built full support, leveraged in the wild bypasses and fixed those up.
They do that now because they care about your security, but to make it difficult to modify (jailbreak) your own devices to run your own software that is not approved by Apple.
What they do is against your interests, for them to keep the monopoly on the App Store.
And after all that hardcore engineering work is done, iMessage still has code paths leading to dubious code running in the kernel, enabling 0-click exploits to still be a thing.
That's one way to look at it, but if perfection is the only goal post then no one would ever get anywhere.
[dead]
One of the knock on benefits of this too is increased security across all platforms as long as someone exercises that code path on one of apples new processors with a hardened runtime.
In theory it makes it easier to catch stuff that you can’t simply catch with static analysis and it gives you some level of insight beyond simply crashing.
Google could have added MTE for a couple of years now, but apparently don't want to force it on OEMs as part of their Android certification program, it is the same history as with OS updates.
Don't the Pixels have MTE? Definitely GrapheneOS does, at least to some extent.
Kind of, you need to enable it on developer tools, also Pixels are Google's, not the other OEMs.
https://developer.android.com/ndk/guides/arm-mte
https://source.android.com/docs/security/test/memory-safety/...