> SK runs on the same high speed application processors as XNU/iOS. To make this possible, additional processor privilege levels are required — likely supported by virtualization extensions
Recent Apple phone and laptop SoCs include hardware support for nested virtualization, including the M4 iPad Pro where an exclave is used for the camera LED. Hopefully the next revision of the Apple Platform Security guide will cover SK exclaves and baseband mitigations for Wi-Fi radar sensing, https://help.apple.com/pdf/security/en_US/apple-platform-sec...
XNU is being refactored into a micro-kernel inspired architecture, aiming to reduce its code base, and move security sensitive operations out of it. The memory space isolation is performed with the help of a Secure Page Table Monitor - SPTM. The code signing, entitlement verification, Developer Mode, Restricted Execution Mode, and other security sensitive operations are handled by the Trusted eXecution Monitor - TXM.
> or most likely via ARM’s TrustZone technology. The XNU source code contains several references regarding transitions to and from TrustZone’s concept of a secure world
> it’s a defensive effort on a larger scale than any other end user device manufacturer is currently attempting
Google implemented pKVM on Pixels with hardware nested virtualization a few years ago, and upstreamed the code to Linux mainline, including cooperative de-privileging of TrustZone relative to pKVM L0. But they have not announced defensive features using pKVM/AVF, outside of Debian "Linux Terminal" VM.
It’s important to note that most of those CVEs are to do with vulnerable software that manufacturers put in the TrustZone protected environment (many of which are garbage). There are very few vulnerabilities reported about the hardware itself.
Personally, I've always thought the fact these vulnerabilities keeps happening demonstrates that TrustZone's secure execution environment just isn't designed well.
If you're a phone designer, and you're going to put unlock PIN validation into a trusted execution environment? Sure, makes sense. If you're going to put your widevine DRM code into a trusted execution environment? I guess.
But why did they make a design that means a vulnerability in the DRM code allows an attack on the PIN validation code? That means the attack surface is huge.
You gotta keep these clowns separated if you don't want them spraying each other with water and throwing pies down each other's trousers.
> While I speculated that TrustZone was being used, exclaves may well use the existing SPTM and GXF (Guarded Execution) privilege levels after all. One implication may be that there is no hard reason they couldn't be supported on iPhone 13 and higher, aside from RAM requirements and development effort. Make no mistake these are huge undertakings even for Apple.
Recent Apple phone and laptop SoCs include hardware support for nested virtualization, including the M4 iPad Pro where an exclave is used for the camera LED. Hopefully the next revision of the Apple Platform Security guide will cover SK exclaves and baseband mitigations for Wi-Fi radar sensing, https://help.apple.com/pdf/security/en_US/apple-platform-sec...
> Apple specific additions to SPTM
SPTM reverse engineering, https://www.df-f.com/blog/sptm3
> or most likely via ARM’s TrustZone technology. The XNU source code contains several references regarding transitions to and from TrustZone’s concept of a secure world150+ TrustZone CVEs, https://www.cve.org/CVERecord/SearchResults?query=trustzone
> it’s a defensive effort on a larger scale than any other end user device manufacturer is currently attempting
Google implemented pKVM on Pixels with hardware nested virtualization a few years ago, and upstreamed the code to Linux mainline, including cooperative de-privileging of TrustZone relative to pKVM L0. But they have not announced defensive features using pKVM/AVF, outside of Debian "Linux Terminal" VM.