In the News: Apple Silicon Macs
Currently, iOS devices run on chips designed by Apple and ARM, manufactured solely for Apple by Samsung and TSMC (interesting aside: some older iOS devices had performance differences depending on the manufacturer of their CPU, down to fabrication differences). In contrast, MacOS computers run on Intel CPUs and GPUs.
This week, as part of their Developer Conference, Apple announced “Apple Silicon Macs”; their computers are going to run on custom ARM-based processors, just like their phones and tablets. By “Apple Silicon Macs” they mean “Macs running on Apple/ARM designed chips made for us”. It’s not the first time they’ve made such a change, the last one being the move to Intel from PowerPC, in 2005.
This means the same apps and ecosystems for iOS and macOS, and much more similar architecture and security for Apple mobile devices and computers.
The news represents the first step in a long mooted strategic shift to ARM and away from Intel. Above all, this move gives Apple more control of the core elements to their computer ranges, on a par with their mobile devices. It’s not a good time for Intel, who from a security perspective have spent the past couple of years having to deal with newly-found security bugs in decades old features of their chips (see this summary). In contrast
Plus there are secondary benefits from the advantages of ARM chips, such as improved power consumption, which was mentioned at one of the Worldwide Developers Conference (WWDC) events (from Apple, via Ars Technica):
So, what do we know about what these new chips will mean for Macs? It’s all explained at a high level in this video, from which I’ve made the following notes and taken many screenshots.
Currently, macOS devices have the following setup, based on several discrete hardware components:
The new ARM architecture means most of these discrete components can be integrated into one chip, with shared memory. This gives speed benefits as shared memory and components replace busses and external interfaces. Plus, it means they can port the “iOS Silicon advancements” from their iOS chips across to macOS chips, such as:
It also supports asymmetric multiprocessing, which allows for multiple cores of differing power, something that’s been in mobile devices for a long time (see ARM big.LITTLE for an example):
It also means the porting of several hardware-backed security measures from iOS to macOS devices, including:
A standard defensive technique is to mark memory as either Read-Writable (R/W) or eXecutable (X). Memory pages are either writable or executable, but many modern Just-In Time (JIT) compilers break this model as they require memory to be both R/W and X.
So, the new model supports this, with per-thread switching between RW and X permissions:
Kernel Integrity Protection
Kernel Integrity Protection (KIP) means changes to how Kernel Extension (KExts) are loaded and unloaded — it will mean a reboot for any changes to KExts. This isn’t as much of an issue for KExt developers as it might have been, as last year’s driver kit enables user-level drivers. Moving drivers to run at a user-level instead of the system-level improves security and reliability, as drivers can be monitored by the kernel and other high-level security functions, and if exploited don’t grant access to the kernel.
Pointer Authentication Codes
macOS will get the same pointer protections as newer iPhones, which will be enabled for kernel, system apps and services. This is one of the first implementations of the ARM Pointer Authentication introduced in v8.3 of the ARM instruction set.
Device Memory Isolation
All system devices will have their own Input/Output Memory Management Unit (IOMMU), which isolates them from each other. This means that devices can’t talk to each other as they can’t see outside their own memory range. This means, in theory, no more attacks from devices to other devices or the kernel.
Whilst it’s great to see Apple planning on improving Mac security, and we should always cheer steps forward in security, of course it doesn’t mean Macs will suddenly be perfectly secure. Everyone makes mistakes, and Apple didn’t have a great track record with iOS 13, which had the most updates of any iOS version.
Attackers are already working to get around these new protections to exploit iOS devices. For example, see this and this bypass for iOS kernel protection, and this work on breaking pointer authentication.
And don’t forget, mistakes in hardware are much harder to mitigate.
Rosetta provides backwards-compatibility for Intel x86/64 apps. It “translates executable code” to run on the new architecture. Interestingly, all code is signed to a machine which duplicates the iOS app deployment model. It includes “hardened run-time protections”:
Again, Apple are replicating iOS functionality in macOS, including secure boot (the iOS version is described in detail in their security whitepaper):
On macOS this includes a recovery mechanism:
The old set of key-combination start-up options are to be replaced by a simple user interface, for example with Recovery:
And for target disk mode:
macOS can securely boot from external disk:
Security policy is now applied per-OS:
New Macs will have always-on volume protection just like the iOS in-line encryption. This can be tied to a user, as “when FileVault is on this encryption is tied to user credentials”. They will also support secure hibernation:
And a single login that includes FileVault:
The new recovery mechanism allows you to erase and reinstall macOS and macOS Recovery using the System Recovery partition.
iOS devices use a Secure Enclave Processor (SEP) to underpin crucial security features, which is a part of the custom processors. macOS devices have a separate T2 chip, but the coverage hasn’t mentioned whether this will stay as a discrete component or be a part of the new processor.
As covered here what happens with Windows support? Spoiler: it won’t work.
Originally published at https://6point6.co.uk.