I smell AI writing assistance. Which is a shame because this is otherwise very good and well-collated information about Apple's security. But AI loves to use bullet point lists just for the hell of it and it makes the information here smell way less reliable than it actually is.
I'm also not sure if it's 100% accurate. My (possibly wrong) understanding of the guarded execution feature is that each GL is paired with a normal ARM EL. i.e. GL2 constrains EL2, GL1 constrains EL1, etc. XNU lives in EL2 so SPTM lives in GL2, and GENTER/GEXIT move you between ELx and GLx through a secure call vector. In contrast, this guide refers to GL0 being the "standard XNU kernel context" even though XNU lives in EL2 on macOS. Furthermore, on device OSes (iOS/iPadOS/etc) they put a second kernel in GL1 and various enforcement policy tools (i.e. code signing policy, camera indicator policy) in GL0[0]. So I'm not sure how macOS putting XNU in GL0 makes sense?
[0] XNU source refers to this concept as an Exclave, which itself can be grouped with other isolated resources as a Conclave.
I think the article is being stealth edited which is a bit annoying; its explanation of guarded execution is now closer to yours, which I think is accurate.
I genuinely hope I'm not being used as a reference for how Apple device security works as I have absolutely NO credentials for that beyond "read a lot of posts from people on the Asahi Linux project"
> I smell AI writing assistance. Which is a shame […]
I have met multiple brilliant, very bright, and talented people (mathematicians, physicists, doctors) who excel at what they know and do, yet immensely struggle to spell, write, or both. There are also people who do not like to write (whatever the reason is).
GenAI has been a great boon for such a type of person as it dissolves their struggle – they convey the idea to the machine (however awful the scribe is) and GenAI handles the grammar and style.
Granted, it is different from «hey, GenAI pet, write me a blog post on XYZ».
For example, it says quite unambiguously that the bootloader is encrypted directly with the GID key (loading the LLB ciphertext into the AES engine), but that's not how it works, the GID key is used to decrypt the LLB's KBAG into an AES key:IV pair and that is used to decrypt the LLB.
More:
> The behavior of the Boot ROM changes fundamentally based on the "Security Domain" fuse.
>
> Production (CPFM 01):
Security Domain (SDOM) is a different thing than CPFM. And production devices have CPFM 03.
> CHIP (Chip ID): Identifies the SoC model (e.g., 0x8101 for M1).
The M1 SoC is 0x8103.
Due to Brandolini's Law I will not continue to list everything else that is wrong here...
This quickly went from Brandolini's Law to Cunningham's Law. Learn how Apple's boot process works by explaining it wrong and waiting for people to correct you!
Yeah, definitely not at all a fan of stealth editing.
I suspected LLM rewriting or generation but I don't possess enough knowledge into how the Apple pre-boot environment works to make an accurate judgement on the accuracy of the post. But I definitely had very strong suspicions of LLM influence with all the bullet lists and hem-hawing the post does; I would expect that someone who successfully reverse engineered the boot chain this thoroughly wouldn't need to hedge anything but Apple's rationale on why they did things. But maybe I'm too overly focused on details.
That's exactly how LLMs are so effective: the text looks impressive to people who don't possess enough knowledge to make an accurate judgement. Meanwhile actual researchers with Apple experience found clear errors on a quick skim.
The large amount of rewriting being done within 5 minutes is another sign of LLM...
Can you recommend a more factual and complete overview on Apple security architecture and bootchain than this bug-ridden article? I'm interested in hardware security (models).
I'm also not sure if it's 100% accurate. My (possibly wrong) understanding of the guarded execution feature is that each GL is paired with a normal ARM EL. i.e. GL2 constrains EL2, GL1 constrains EL1, etc. XNU lives in EL2 so SPTM lives in GL2, and GENTER/GEXIT move you between ELx and GLx through a secure call vector. In contrast, this guide refers to GL0 being the "standard XNU kernel context" even though XNU lives in EL2 on macOS. Furthermore, on device OSes (iOS/iPadOS/etc) they put a second kernel in GL1 and various enforcement policy tools (i.e. code signing policy, camera indicator policy) in GL0[0]. So I'm not sure how macOS putting XNU in GL0 makes sense?
[0] XNU source refers to this concept as an Exclave, which itself can be grouped with other isolated resources as a Conclave.