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.
I buy Apple products not just because they do a great job with security and privacy, but because they do this without needing to do it. They could make plenty of money without going so deep into these features. Maybe eventually it’d catch up with them but it’s not like they even have competition forcing them to care about your privacy.
Their commitment to privacy goes beyond marketing. They actually mean it. They staffed their security team with top hackers from the Jailbreak community… they innovated with Private Relay, private mailboxes, trusted compute, multi-party inference…
I’ve got plenty of problems with Apple hypocrisy, like their embrace of VPNs (except for traffic to Apple Servers) or privacy-preserving defaults (except for Wi-Fi calling or “journaling suggestions”). You could argue their commitment to privacy includes a qualifier like “you’re protected from everyone except for Apple and select telecom partners by default.”
But that’s still leagues ahead of Google whose mantra is more like “you’re protected from everyone except Google and anyone who buys an ad from Google.”
Whenever I read about it, I am surprised at the complexity of iOS security. At the hardware level, kernel level, all the various types of sandboxing.
Is this duct tape over historical architectural decisions that assumed trust? Could we design something with less complexity if we designed it from scratch? Are there any operating systems that are designed this way?
I think that there's also inherent trust in "hardware security" but as we all know its all just hardcoded software at the end of the day, and complexity will bring bugs more frequently.
It’s been designed with lower user trust since day one, unlike other OSes of the era (consumer Windows, Mac’s classic OS).
Just how much you can trust the user has changed overtime. And of course the device has picked up a lot of a lot of of capabilities and new threats such as always on networking in various forms and the fun of a post Spectre world.
>Is this duct tape over historical architectural decisions that assumed trust?
Yes, it's all making up for flaws in the original Unix security model and the hardware design that C-based system programming encourages.
> Could we design something with less complexity if we designed it from scratch? Are there any operating systems that are designed this way?
Yes, capability architecture, and yes, they exist, but only as academic/hobby exercises so far as I've seen. The big problem is that POSIX requires the Unix model, so if you want to have a fundamentally different model, you lose a lot of software immediately without a POSIX compatibility shim layer -- within which you would still have said problems. It's not that it can't be done, it's just really hard for everyone to walk away from pretty much every existing Unix program.
Yes, but they're architectural decisions made at Bell Labs in the 70s. iOS was always designed with the assumption that no one is trustworthy[0], not even the owner of the device. So there is a huge mismatch between "70s timesharing OS" and "phone that doesn't believe you when you say 'please run this code'" That being said, most of these security features are not duct-tape over UNIXisms that don't fit Apple's walled garden nonsense. To be clear, iOS has the duct-tape, too, but all that lives in XNU (the normal OS kernel).
SPTM exists to fix a more fundamental problem with OS security: who watches the watchers? Regular processes have their memory accesses constrained by the kernel, but what keeps the kernel from unconstraining itself? The answer is to take the part of the kernel responsible for memory management out of the kernel and put it in some other, higher layer of privilege.
SPRR and GLs are hardware features that exist solely to support SPTM. If you didn't have those, you'd probably need to use ARM EL2 (hypervisor) or EL3 (TrustZone secure monitor / firmware), and also put code signing in the same privilege ring as memory access. You might recognize that as the design of the Xbox 360 hypervisor, which used PowerPC's virtualization capability to get a higher level of privilege than kernel-mode code.
If you want a relatively modern OS that is built to lock out the user from the ground-up, I'd point you to the Nintendo 3DS[1], whose OS (if not the whole system) was codenamed "Horizon". Horizon had a microkernel design where a good chunk of the system was moved to (semi-privileged) user-mode daemons (aka "services"). The Horizon kernel only does three things: time slicing, page table management, and IPC. Even security sensitive stuff like process creation and code signing is handled by services, not the kernel. System permissions are determined by what services you can communicate with, as enforced by an IPC broker that decides whether or not you get certain service ports.
The design of Horizon would have been difficult to crack, if it wasn't for Nintendo making some really bad implementation decisions that made it harder for them to patch bugs. Notably, you could GPU DMA onto the Home Menu's text section and run code that way, and it took Nintendo years to actually move the Home Menu out of the way of GPU DMA. They also attempted to resecure the system with a new bootloader that actually compromised boot chain security and let us run custom FIRMs (e.g. GodMode9) instead of just attacking the application processor kernel. But the underlying idea - separate out the security-relevant stuff from the rest of the system - is really solid, which is why Nintendo is still using the Horizon design (though probably not the implementation) all the way up to the Switch 2.
[0] In practice, Apple has to be trustworthy. Because if you can't trust the person writing the code, why run it?
12 comments
[ 2.8 ms ] story [ 32.5 ms ] threadNot 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.
Their commitment to privacy goes beyond marketing. They actually mean it. They staffed their security team with top hackers from the Jailbreak community… they innovated with Private Relay, private mailboxes, trusted compute, multi-party inference…
I’ve got plenty of problems with Apple hypocrisy, like their embrace of VPNs (except for traffic to Apple Servers) or privacy-preserving defaults (except for Wi-Fi calling or “journaling suggestions”). You could argue their commitment to privacy includes a qualifier like “you’re protected from everyone except for Apple and select telecom partners by default.”
But that’s still leagues ahead of Google whose mantra is more like “you’re protected from everyone except Google and anyone who buys an ad from Google.”
[0] https://security.apple.com/blog/apple-security-bounty-evolve...
Is this duct tape over historical architectural decisions that assumed trust? Could we design something with less complexity if we designed it from scratch? Are there any operating systems that are designed this way?
I think that there's also inherent trust in "hardware security" but as we all know its all just hardcoded software at the end of the day, and complexity will bring bugs more frequently.
It’s been designed with lower user trust since day one, unlike other OSes of the era (consumer Windows, Mac’s classic OS).
Just how much you can trust the user has changed overtime. And of course the device has picked up a lot of a lot of of capabilities and new threats such as always on networking in various forms and the fun of a post Spectre world.
https://medium.com/@tunacici7/sel4-microkernel-architecture-...
It's missing "the rest of the owl", so to speak, so it's a bit of a stretch to call it an operating system for anything more than research.
Yes, it's all making up for flaws in the original Unix security model and the hardware design that C-based system programming encourages.
> Could we design something with less complexity if we designed it from scratch? Are there any operating systems that are designed this way?
Yes, capability architecture, and yes, they exist, but only as academic/hobby exercises so far as I've seen. The big problem is that POSIX requires the Unix model, so if you want to have a fundamentally different model, you lose a lot of software immediately without a POSIX compatibility shim layer -- within which you would still have said problems. It's not that it can't be done, it's just really hard for everyone to walk away from pretty much every existing Unix program.
SPTM exists to fix a more fundamental problem with OS security: who watches the watchers? Regular processes have their memory accesses constrained by the kernel, but what keeps the kernel from unconstraining itself? The answer is to take the part of the kernel responsible for memory management out of the kernel and put it in some other, higher layer of privilege.
SPRR and GLs are hardware features that exist solely to support SPTM. If you didn't have those, you'd probably need to use ARM EL2 (hypervisor) or EL3 (TrustZone secure monitor / firmware), and also put code signing in the same privilege ring as memory access. You might recognize that as the design of the Xbox 360 hypervisor, which used PowerPC's virtualization capability to get a higher level of privilege than kernel-mode code.
If you want a relatively modern OS that is built to lock out the user from the ground-up, I'd point you to the Nintendo 3DS[1], whose OS (if not the whole system) was codenamed "Horizon". Horizon had a microkernel design where a good chunk of the system was moved to (semi-privileged) user-mode daemons (aka "services"). The Horizon kernel only does three things: time slicing, page table management, and IPC. Even security sensitive stuff like process creation and code signing is handled by services, not the kernel. System permissions are determined by what services you can communicate with, as enforced by an IPC broker that decides whether or not you get certain service ports.
The design of Horizon would have been difficult to crack, if it wasn't for Nintendo making some really bad implementation decisions that made it harder for them to patch bugs. Notably, you could GPU DMA onto the Home Menu's text section and run code that way, and it took Nintendo years to actually move the Home Menu out of the way of GPU DMA. They also attempted to resecure the system with a new bootloader that actually compromised boot chain security and let us run custom FIRMs (e.g. GodMode9) instead of just attacking the application processor kernel. But the underlying idea - separate out the security-relevant stuff from the rest of the system - is really solid, which is why Nintendo is still using the Horizon design (though probably not the implementation) all the way up to the Switch 2.
[0] In practice, Apple has to be trustworthy. Because if you can't trust the person writing the code, why run it?
[1] https://www.reddit.com/r/3dshacks/comments/6iclr8/a_technica...
https://sneak.berlin/20231005/apple-operating-system-surveil...