This is a really interesting deep dive but why does the article hedge so much? For example, in the first few sections it says things like "... typically reveals the following sequence" or "The Boot ROM sets a specific control bit in the AES configuration register (e.g., AES_CMD_USE_GID)", which makes it sound like the author wasn't actually sure if any of this was accurate and was guessing.
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).
It's basically all AI-generated. There are significant omissions and errors for any flow that hasn't previously been reversed engineered. The launchd stuff has details that are just wrong.
I use it too but 106 "e.g."s in a single page? That's how many there are now. Not to mention it's full of inconsistencies and being edited multiple times.
I think the author might have left an LLM agent in a loop fixing it whenever HN points out an error or finds something new to add on the internet.
Sometimes? Even on HN, where people are in the top 20% of "not making writing mistakes", compared to the general population, I see more people using i.e. wrong than I see people using it right. And sure descriptivism so now it just means that blahblah, it sucks because we already have e.g. for that and it makes i.e. pointless.
The security of the Apple ecosystem is miles ahead of others. Every time I reverse engineer some component of their OS, it is very different from what I've seen before. I always find myself surprised by their thoughtfulness and engineering craft.
Recently I've taken on their code signing component. The concepts they've created, such as identifying applications by their "designated requirements" is a stroke of genius. It makes the system completely stateless and capable of almost anything without auxiliary data structure or additional code.
I've seen other engineering teams try and fail at building something similar, and never with such powerful simplicity.
"In this case, the federal government prohibited us from sharing any information," the company said in a statement. "Now that this method has become public we are updating our transparency reporting to detail these kinds of requests."
“At Apple, we are always working to defend our users against even the most complex cyberattacks. The steps we’re taking today will send a clear message: in a free society, it is unacceptable to weaponise powerful state-sponsored spyware against those who seek to make the world a better place,”
"The app in question is called “LassPass Password Manager” and lists Parvati Patel as the developer. The app attempts to copy our branding and user interface..."
The Pegasus project, an investigation into NSO by the Guardian and other media outlets, coordinated by the French media group Forbidden Stories, has documented dozens of examples in which NSO’s spyware was used to attack users of Apple’s iPhone. In some cases, a vulnerability in the company’s iMessage feature, which could be penetrated by Pegasus, was used against journalists, human rights activists and other members of civil society.
The source is describing an iMessage exploit known as FORCEDENTRY, which can be used to deliver a persistent hardware backdoor (Pegasus) to an iPhone. Often, Apple is unable to detect the persistent exploit and therefore incapable of warning the user that they have a backdoored device: https://9to5mac.com/2025/02/20/apple-currently-only-able-to-...
Will this enable someone who buys an apple laptop to boot directly into a third-party OS, from a thumb drive? Last I heard, they were still too locked down to allow it.
Or you can just sign your Linux kernel from macOS recovery mode, which is what the Asahi Linux installer does already. No need for weird hacks.
You also don't have "kernel access" in macOS. After boot, the memory region corresponding to the macOS kernel is marked as read-only at the memory controller level.
> Or you can just sign your Linux kernel from macOS recovery mode, which is what the Asahi Linux installer does already. No need for weird hacks.
Does that work for USB boot?
> You also don't have "kernel access" in macOS. After boot, the memory region corresponding to the macOS kernel is marked as read-only at the memory controller level.
You can turn that off from recovery mode. (see `bputil`) It's needed to use dtrace.
Obviously, this article might not result in any concrete improvements for Apple owners, but why do you say that UEFI the only way to boot to a thumb drive?
Final Thought:
macOS is no longer just a Unix system. It is a distributed system running on a single die, governed by a hypervisor that doesn't exist in software. The kernel is dead; long live the Monitor.
This is a really interesting deep dive but why does the article hedge so much? For example, in the first few sections it says things like "... typically reveals the following sequence" or "The Boot ROM sets a specific control bit in the AES configuration register (e.g., AES_CMD_USE_GID)", which makes it sound like the author wasn't actually sure if any of this was accurate and was guessing.
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».
This article is definitely the latter, not just "fixing grammar".
Perhaps using AI assistance is good OPSEC. It could help to shield the author from stylometry or author profiling.
And then the author posts it himself to Hacker News. Nah, that's not opsec.
There's many factual errors in this AI slop.
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...
They just fixed the KBAG thing.
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!
All of these errors have now been stealth-corrected.
New strategy discovered: Ask LLM to write article, nerdsnipe HN into correcting it, feed corrections back into LLM until people stop complaining
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).
It's basically all AI-generated. There are significant omissions and errors for any flow that hasn't previously been reversed engineered. The launchd stuff has details that are just wrong.
Do you know of a much more accurate deep dive? I'd love to learn all this from a source that is actually trustworthy/authentic.
If you're new to the topic, this is a good place to start https://support.apple.com/en-lamr/guide/security/welcome/web
It's AI assitance. If you search for "e.g." the page lights up like a christmas tree. There's 90 appearances if "e.g."
I have never seen this frequency before.
Or maybe fully AI-generated. There's many factual errors in the article too.
Damn is that a new signal? I use "e.g." all the time. Now I can't use the em dash or that I suppose or risk being called out for ai gen content
I use it too but 106 "e.g."s in a single page? That's how many there are now. Not to mention it's full of inconsistencies and being edited multiple times.
I think the author might have left an LLM agent in a loop fixing it whenever HN points out an error or finds something new to add on the internet.
> e.g., AES_CMD_USE_GID
Sometimes people mix up “i.e.” (“id est”; “that is”) and “e.g.” (“exempli gratia”; “for example”).
Of course, only the author knows if this case was a mix up, or if they really wrote what they meant.
For anyone looking for a more memorable mnemonic, learned them as "I explain" and "example given".
I like "in essence" and "examples given"
Sometimes? Even on HN, where people are in the top 20% of "not making writing mistakes", compared to the general population, I see more people using i.e. wrong than I see people using it right. And sure descriptivism so now it just means that blahblah, it sucks because we already have e.g. for that and it makes i.e. pointless.
The security of the Apple ecosystem is miles ahead of others. Every time I reverse engineer some component of their OS, it is very different from what I've seen before. I always find myself surprised by their thoughtfulness and engineering craft.
Recently I've taken on their code signing component. The concepts they've created, such as identifying applications by their "designated requirements" is a stroke of genius. It makes the system completely stateless and capable of almost anything without auxiliary data structure or additional code.
I've seen other engineering teams try and fail at building something similar, and never with such powerful simplicity.
> The security of the Apple ecosystem is miles ahead of others.
cough iMessage, hardware backdoors cough
There are not any hardware backdoors.
(that you have seen)
After all, it wouldn't be a backdoor if everyone knew about it.
That's a bit disingenuous. Can you substantiate your claims?
Those aren't iMessage hardware backdoors.
You may have skipped my second link. Here it is a second time, with the important quote excerpted: https://www.theguardian.com/technology/2021/nov/23/apple-sue...
The source is describing an iMessage exploit known as FORCEDENTRY, which can be used to deliver a persistent hardware backdoor (Pegasus) to an iPhone. Often, Apple is unable to detect the persistent exploit and therefore incapable of warning the user that they have a backdoored device: https://9to5mac.com/2025/02/20/apple-currently-only-able-to-...[dead]
> The security of the Apple ecosystem is miles ahead of others.
Have you heard about Qubes OS?
Will this enable someone who buys an apple laptop to boot directly into a third-party OS, from a thumb drive? Last I heard, they were still too locked down to allow it.
The bootloader doesn't even have a USB stack capable of reading external storage.
If you have kernel access you can do an OS-to-OS takeover from the original OS. That's how MkLinux worked on old Macs.
Or you can just sign your Linux kernel from macOS recovery mode, which is what the Asahi Linux installer does already. No need for weird hacks.
You also don't have "kernel access" in macOS. After boot, the memory region corresponding to the macOS kernel is marked as read-only at the memory controller level.
> Or you can just sign your Linux kernel from macOS recovery mode, which is what the Asahi Linux installer does already. No need for weird hacks.
Does that work for USB boot?
> You also don't have "kernel access" in macOS. After boot, the memory region corresponding to the macOS kernel is marked as read-only at the memory controller level.
You can turn that off from recovery mode. (see `bputil`) It's needed to use dtrace.
Apple Silicon doesn't support UEFI, so no.
Obviously, this article might not result in any concrete improvements for Apple owners, but why do you say that UEFI the only way to boot to a thumb drive?
Boot loaders like GRUB etc only work with UEFI/BIOS to state the obvious.
Incredible article. int summarizes it well:
Final Thought: macOS is no longer just a Unix system. It is a distributed system running on a single die, governed by a hypervisor that doesn't exist in software. The kernel is dead; long live the Monitor.
Holy cow I was reading and reading and then I realized I was only 10% through!
It's long because it's AI-assisted and they're all bullet point lists all the time.
Can't seem to load it. FF on Android. SSL problem?
Working ok for me
This is top 10 for greatest HN deep dives. I learned something new almost every sentence, and could not complete it on my first attempt.
This is top tier. Well written and insanely detailed.