feature: signed, sealed, delivered? Completing an install

[PaulCharlton]

consider the interaction of the following elements:

1) the nvram parameter boot-volume 2) the standalone Recovery OS (in its own GPT partition named RecoveryOSContainer 3) the Recovery OS paired with the original macOS install 4) the Recovery OS paired with the Asahi install 5) the LocalSecurityPolicies in iBootSystemContainer 6) whether or not the Asahi install is blessed 7) whether or not the Asahi install has an LSP (LocalSecurityPolicy) in iBootSystemContainer / iSCPreboot 8) whether or not the Asahi install is designated as the boot volume in the nvme parameter boot-volume

Consider where each of those conditions is observed to boot during a simple reboot, or a single short press of the power button.

LSP	Blessed	Asahi is Boot Target	What boots?
any	any	false	macOS default
false	false	true	Boot Recovery Console + Standalone Recovery
false	true	true	Boot Recovery Console + Standalone Recovery
true	false (and not overridden by the LSP)	true	Boot Recovery Console + Standalone Recovery
true	true	true	Asahi OS (currently Fedora)

Notes: 1) none of those possibilities [auto] boots to the Recovery OS paired with Asahi. 2) the Standalone Recovery has a Startup Volume tool, but invoking that does not list Asahi OS as an option [speculation: the Startup Volume tool requires a valid LSP, even if the Volume is blessed.

Given: that there are three fundamental ways to boot (ignoring DFU mode) 1) short press power button 2) long press power button until presented with Startup Options 3) short press power button, immediately followed by long press power button

Consider now where each of those conditions is observed to boot during a Startup Options reboot, or a single long press of the power button [noting that the state where Asahi is boot target, but not blessed represents a corrupt install]

LSP	Blessed	Asahi is Boot Target	What boots?
any	false	false	startup picker [macOS, Options]
any	false	true	startup picker [macOS, Options]
any	true	true	startup picker [macOS, Asahi, Options]

Then consider what happens for each of the possible selections:

1) if macOS is chosen, it will boot 2) if Options are chosen, a Recovery Console is launched, but the one you get depends on the nvme boot-volume. 1) If boot-volume is macOS, you will get the Recovery Console paired with macOS 2) if boot-volume is Asahi OS, you will get the standalone Recovery Console 3) if Asahi is chosen, what happens depends on the LSP being present or not. 1) if LSP not present [false], you get the Recovery Console paired with Asahi 1) currently the Asahi OS installer is using this to launch a script which creates the LSP 2) if LSP is present [true], you get the installed Asahi OS instance [w00t!]

The above observations show that the Startup Picker does not care if the targeted option has an LSP, but does care if the targeted option is sealed (blessed), which is different than the iBoot, which requires both LSP+blessed by default.

this is a work-in-progress RFC

notes and observations, feedback requested -- especially if you see different behavior on your system.

the above was observed on a MacBook Air [M2] with fresh DFU install of Sonoma 14.5

I could be wrong about everything

Question: in light of the above, the user would likely have an easier install experience getting the LSP created if the Asahi installer did bless without --setBoot, and we instruct the user to long-press power to get the startup picker, and have them select Asahi|Fedora from there to get the Asahi-paired Recovery OS -- at a minimum, this approach would always boot to a "known-good" state, which will be macOS until the Asahi LSP is created.

Question #2: what do we want the user experience to be if we upgrade Asahi and the boot-volume needs to be re-sealed with bless?

Both questions lead to the fact that Apple needs a method to approve and crypto-sign boot shims. Just as MSFT is the only signer of "Secure Boot" shims for EFI Bios (unless the user adds more approved public keys via their BIOS setup screens).

The apple approved boot shims would apply both the Asahi loader, and would also be needed for any Asahi upgrade tool which used the Upgrade APFS volume method. (or do we just leave a permissive LSP for a boot policy)

[PaulCharlton]

https://support.apple.com/guide/security/contents-a-localpolicy-file-mac-apple-silicon-secc745a0845/web https://support.apple.com/guide/security/boot-modes-sec10869885b/1/web/1

[marcan]

You're wrong about this, and this is where your idea falls apart:

if Asahi is chosen, what happens depends on the LSP being present or not. if LSP not present [false], you get the Recovery Console paired with Asahi

If Asahi is chosen, what happens depends on the .IAPhysicalMedia file in the root of the System volume. If it exists, recoveryOS launches the app it points to. If it does not, and an LSP is present, it boots the OS. If an LSP is not present, then it tries to bless the volume for you. But importantly, none of this has anything to do with the recoveryOS being paired with Asahi. That only depends on the default boot volume. If macOS is the default, then the recoveryOS will not be paired with Asahi, no matter what you pick here, and the installation will fail. This is because the Boot Picker is just a macOS app launched from recoveryOS, and by the time it is displayed, the decision on what recoveryOS paired with what is running has already been made. This is why making Asahi the default boot is a hard requirement for any of this to work.

If you do find a better flow and have the code/proof-of-concept to show how it would work, we're all ears. But so far, as far as I know, what you're proposing here and in #305 is simply impossible.

[PaulCharlton]

I will dig up the Apple documentation I was reading and manually verified -- will post here. My current understanding is that if macOS is the default, and you pick, say "Fedora" in the boot-picker, and "Fedora" fails crypto checks, it will launch the Fedoro-paired Recovery OS if it exists in the same volume group. Even if that Recovery OS is not properly sealed. The security is maintained by the admin (owner) user confirmation right before the Recovery OS is actually launched.

Noting that the tables in the initial comment above are "observations" after a couple of dozen DFU reinstalls for a known-good starting point. I would prefer to keep this issue open for tracking, otherwise we may get a daisy-chain of additional issues referencing this one for context.

[PaulCharlton]

the information I do not have, and do not have a reasonable test lab for, is whether any of these behaviors observed above are different for different Apple Silicon firmware versions or macOS versions, or different for different motherboards/models.

I imagine that there is some dependency on firmware versions, simply because the existing code and flow looks well thought out and tested, but my experience with a fresh out of box MacBook Air M2 has been different that what the code tells me I should see, so I started investigating.

@marcan

[marcan]

You're confusing boot recovery with One True RecoveryOS. Yes, if an OS fails to boot enough times (e.g. due to failing crypto checks) it will launch recoveryOS (for that OS, presumably). This is not a direct action from the boot picker, it follows attempts to actually boot that fail (through multiple reboot cycles). This is immaterial to us, because that 1) does not give you a shell anyway where you can actually do the install (it just tries to do an auto repair IIRC), and 2) is not One True RecoveryOS, which is required for going to Permissive Security, which we need.

The installer needs the user to boot the Asahi paired recoveryOS as One True RecoveryOS. The only way to boot to One True RecoveryOS is to hold down the power button at boot, and the only recoveryOS that will boot is the one paired to the current default boot volume (or System RecoveryOS if that is damaged/missing, but that doesn't help).

The security is maintained by the admin (owner) user confirmation right before the Recovery OS is actually launched.

This is incorrect. The only way to trigger 1TR is via the single hold power button chord. This is by design. It is how you assert physical presence. Any other way of entering recoveryOS will not be 1TR and will not work. Non-1TR is good enough to set up boot policies for vanilla macOS without tatsu (Reduced Security) but is not enough to install a custom kernel, which requires Permissive Security.

The way 1TR worked was different in the 11.x era (back then it was always System RecoveryOS) and indeed in that case you would not have to set the default boot OS to make things work, but that is ancient history. Since 12.x what I said above is true.

[PaulCharlton]

@marcan if you can identify particular lines in the formatted tables in my opening comment above that you disagree with, I will quite gladly re-test my observations there, and even video the experience if that's a good way to share. I don't mind being wrong, but I saw what I saw unless I lost track of where I was somewhere in the middle of the process. I can run a script in each Recovery Console presented to me to document what it booted from, mounted, etc, if there's some additional context you would like to see .. certainly the "paired", "1TR" status, volume group UUID and a diskutil dump of that. Also mounts.

To summarize the path in those tables above that seemed to work for me (I will retest that path) is

1. macOS as default boot
2. from a shutdown state, long-press until boot picker
3. pick Fedora Asahi
4. boot fails, and gets to boot recovery, which then can launch RecoveryOS
5. this Recovery OS is the one paired with Fedora, and launches the step2.sh
6. next and subsequent boots are Fedora Asahi

I will re-test that path from a DFU wipe and post further results here.

[marcan]

Your sequence of events doesn't make sense and I can't reproduce it.

1. macOS as default boot

Okay.

2. from a shutdown state, long-press until boot picker

Sure.

3. pick Fedora Asahi

Presumably in a state without the .IAPhysicalMedia trigger and with a full or reduced security boot policy, yes?

Alternatively, with no Boot Policy? (I also tested this)

4. boot fails

Yes, because it tries to start XNU without a valid root filesystem.

and gets to boot recovery

No. When boot fails with macOS set as the default boot, the system reboots directly into macOS, not the OS that was selected for one-time boot. Boot needs to fail multiple times in a row (counted by a scratch register in the PMU) to trigger boot recovery.

If you instead try this with no Boot Policy at all, then indeed you get to Boot Recovery after an early failure, but that doesn't lead anywhere because...

7. which then can launch RecoveryOS

Boot Recovery, the Boot Picker, etc. are all already recoveryOS, just running different apps. There is no such thing as "launching recoveryOS" from those states. It already is recoveryOS, a specific one that was already selected, and switching to another one requires a reboot.

I did not know this, but it is indeed possible to cancel the authentication dialog, take a trip through Boot Picker, exit out again, and land in the recoveryOS main menu. But, exactly as I predicted, this is 1) the paired recoveryOS to the default boot macOS, not Fedora, and 2) not 1TR, but rather ordinary recoveryOS.

this Recovery OS is the one paired with Fedora

Nope.

and launches the step2.sh

There is no mechanism for this to happen automatically here, that would happen at step 3 with the .IAPhysicalMedia trigger. If you instead pull up a Terminal and do it manually, it will fail, because...

next and subsequent boots are Fedora Asahi

This is impossible because this is neither 1TR nor the recoveryOS paired to Fedora, both of which are required conditions for step2.sh to be capable of succeeding. If you attempt to run step2.sh in this scenario, it will fail with an "AP Boot Mode" error (i.e. this is not One True RecoveryOS).

[marcan]

To add, this is what actually happens in your scenarios. First, two things happen behind the scenes which you are not aware of, and I think is why you are so confused:

1. If you boot via a long press of the power button, recoveryOS is started as One True RecoveryOS, paired with whichever OS is set in the boot-volume nvram var.
2. If you boot via tap-and-long-press the power button, System recoveryOS is started as Ordinary RecoveryOS (this is not paired with any OS).
3. If the boot mechanism is anything else, the paired recoveryOS starts, but the boot mode is not One True RecoveryOS, it's Ordinary RecoveryOS

At this point, the decision of what recoveryOS is running, what it's paired with or not, and whether it's 1TR or ordinary, is already made, and your selection in the menu cannot change it without a full system reboot, which necessarily loses 1TR status in all cases. The Boot Picker you see is already a full blown recoveryOS instance.

Then, this happens:

1. if macOS is chosen, the system reboots into it
2. if Options are chosen, a Recovery Console is launched, but the one you get depends on the nvme boot-volume (because recoveryOS is already running and the decision was made above).
3. if Asahi is chosen, what happens depends on .IAPhysicalMedia and the LSP being present or not.
   • if .IAPhysicalMedia is present, the recoveryOS which is already running because that's what the Boot Picker is switches to the recoveryOS view and automatically launches step2.sh. This is the trick the installer uses to avoid having to tell users to run step2.sh manually.
   • if LSP is present and Full or Reduced Security (a non-fuOS LSP), the system reboots into XNU which then fails to boot, and reboots again back to the default OS (nvram boot-volume). If this is Asahi too, after 5 or so failed boot loops, it goes into Boot Recovery
   • if LSP is not present, the system reboots and fails immediately in iBoot due to the missing LSP, directly triggering Boot Recovery
   • if LSP is present and Reduced Security with m1n1 as fuOS, Asahi boots.

And crucially, whatever Boot Recovery you get is an instance of Ordinary RecoveryOS paired to the default boot OS, which is incapable of configuring a Permissive Security boot policy, and therefore cannot be used to run step2.sh.