# The Open OS Ecosystem on Apple Silicon Macs

## Foreword

This document attempts to explain the Apple Silicon (i.e. M1 and later) Mac boot ecosystem (henceforth "AS Macs"), including both hard platform requirements as well as our vision for how open OSes should interoperate within the platform.

It is intended for developers and maintainers of Linux, BSD and other OS distributions and boot-related components, as well as users interested in the platform, and its goal is to cover the overall picture without delving into excessive technical detail. Specifics should be left to other wiki pages. It also omits details that only pertain to macOS (such as how kernel extensions work and are loaded).

The information here is based on how things work in system firmware and macOS versions 12.0 (Monterey) and later. A number of rapid design changes took place in the first year after the initial M1 Mac announcement; although older 11.x firmwares are usable, they are obsolete and buggy in various ways, and attempting to cover these changes would make things too confusing. We expect users wishing to run open OSes to run system firmware corresponding to macOS 12.1 or later, for practical reasons (though they may have older versions of macOS itself installed).

The ideas in this document (other than the *Introduction to Apple Silicon* section, which documents the platform) are not intended to set hard requirements or rules; anyone is of course free (and encouraged) to go their own way if they so choose. Rather, we would like to agree on a set of standards that make it easier for different OSes to co-exist and be installed by end users, aiming to make the process as simple, seamless, and future-proof as possible.

This document is a draft, and we welcome all commentary and discussion in order to help shape the future of how to build an open OS ecosystem on these platforms. Please drop by #asahi on OFTC if you have general questions or feedback, or ping us on #asahi-dev if you are a developer and would like to discuss technical aspects ([further info](https://asahilinux.org/community/)).

## Introduction to Apple Silicon

This section covers the system design, that is, the hard requirements imposed by the platform on how OSes load and run.

### Design goals

AS Macs have the following design goals:

* Made for macOS
* Open to other OSes
* Mandatory secure boot (with user control)
* Secure even against attackers with physical access
* Resistant to supply-chain attacks
* Defense in depth (no blind trust in coprocessors/firmware)
* Native dual/multiboot with backwards compatibility
* Brick-proof
* Recoverable security (can be restored to known-good state by users)

Keep these design goals in mind as you read through this document, as they explain a lot of the decisions that went into the system architecture. Apple's approach to third-party OSes is essentially "have fun". We do not have any expectations of direct support, documentation, or additional development effort from them, nor do we expect them to attempt to hinder third-party OSes in any deliberate way. They have explicitly developed the ability to securely run third-party OSes and bootloaders on these machines, and left the rest to us.

Apple documents much of their security design in their [platform security guide](https://support.apple.com/guide/security/welcome/web), which should be considered the authoritative reference for these platforms. Nonetheless, the guide does not go into the fine technical points of the system, and we have learned about many further details through experimentation and reverse engineering.

These systems are engineered to run macOS, and make no explicit concessions for supporting other OSes; the ability to boot custom kernels can be viewed as official support for self-compiled builds of the [macOS kernel](https://github.com/apple/darwin-xnu), and non-macOS OSes need to behave like macOS does as far as their interactions with the rest of the platform. In other words, the ABI specification for every aspect of boot and firmware interaction is "whatever macOS does". There is no attempt to enforce actual usage of macOS (no evil checks or anything of that sort), so the system is open to any OS as long as it follows the macOS boot ABI.

#### On secure boot, user control, and licensing

It would be remiss not to briefly cover where these machines stand in terms of user control and trustability. Apple Silicon machines are designed first and foremost to provide a secure environment for typical end-users running macOS as signed by Apple; they prioritize user security against third-party attackers, but also attempt to limit Apple's own control over the machines in order to reduce their responsibility when faced with government requests, to some extent. In addition, the design preserves security even when a third-party OS is installed. The entire architecture is complicated and the details subtle, but to summarize a few key points:

* Boot components are signed and opaque (encrypted)
* Runtime components (e.g. firmware and macOS itself) are signed and transparent (plaintext)
** With the exception of the SEP (a TPM equivalent), which is optional and disabled by default
* Brick recovery / total system flash (DFU) requires phoning home
* Normal operation, including OS installs, can be performed off-line with physical user presence. It is possible to take an out-of-the-box Mac and install Linux on it without ever connecting it to a network.
* Owner control is asserted on first boot (you become machine owner by going through the macOS setup flow and creating the first admin user).
* The normal bootloader flow is minimal and has a small attack surface (no USB, network, etc.)
* No runtime blobs have total system access (no ME, no PSP, no TrustZone, nothing of that sort). All blobs are running behind IOMMUs or similar firewalls. All code running on the main CPUs is under the control of the OS.

This puts them somewhere between x86 PCs and a libre-first system like the [Talos II](https://www.raptorcs.com/TALOSII/) in terms of freedom to replace firmware and boot components; while a number of blobs are required in order to boot the system, none of those have the ability to take over the system or compromise it post-boot (unlike, say, Intel ME and AMD PSP on recent systems, or the DMA-capable chips on the LPC bus running opaque blobs that exist on even [old ThinkPads](https://ryf.fsf.org/products/TET-X200)).

From a security perspective, these machines may possibly qualify as the most secure general purpose computers available to the public which support third-party OSes, in terms of resistance to attack by non-owners. This is, of course, predicated on some level of trust in Apple, but some level of trust in the manufacturer is required for any system (there is no way to prove the non-existence of hardware backdoors on any machine, so this is not as much of a sticking point as it might initially seem).

This design does make it somewhat more awkward for users to install a third-party OS than we're used to on other platforms (this is standard fare in order to protect against malware and users being misled into compromising their machines), and this is covered in the rest of this guide.

On the licensing front:

* You *do* have to click through Apple's EULA in order to use the machines at all.
* Apple gives users explicit permission to run their own OS in their EULA.
* Apple does not give users permission to redistribute system firmware, but
* Apple provides all current and past versions of complete system images (firmware and macOS) on an well-known, unauthenticated HTTPS CDN, and
* Apple's EULA grants all Mac owners a license to use these images.

As with all EULAs, there are some nonsensical points in Apple's (lawyers always seem to be out of sync with actual product direction and design), but reading between the lines we believe everything we're doing is kosher for practical purposes.

### Storage

AS platforms have two main kinds of storage: NOR Flash and NVMe.

NOR is formatted as raw regions and contains:

* 1st stage bootloader (iBoot1/LLB)
* System-global firmware
* Platform configuration data (syscfg, read-only)
* Factory test logs
* NVRAM (config variables, read-write)

NVMe is a GPT volume and contains:

* System-global storage (iBoot System Container; iSC) including:
 * Boot policies (think boot configs, but secure) (Preboot)
 * SEP secure storage (xARTS)
 * Misc system config data
* One or more APFS container partitions
 * Each containing one or more bootable OSes sharing a container, each comprising
  * Preboot volume subfolder
   * 2nd stage bootloader (iBoot2)
   * Apple Device Tree
   * OS-paired firmware
   * OS kernel (XNU)
  * OS-paired recoveryOS image (in Recovery volume)
  * Per-OS root & data filesystem volumes (may be empty)
* System-global recoveryOS image (+ optional fallback)

There are no restrictions on additional partitions and types; they are ignored by Apple's tooling.

Note that the system does not use an EFI system partition (and does not run EFI). OS selection is designed around APFS containers and partitions containing 

AS Macs are designed to be brick-proof. They can be recovered from another machine by using a USB cable and booting from ROM, even if all NOR and NVMe contents are destroyed (\* NOR destruction untested). This is [officially documented](https://support.apple.com/guide/apple-configurator-2/revive-or-restore-a-mac-with-apple-silicon-apdd5f3c75ad/mac) using another Mac. We have alternative [open source tooling](https://github.com/libimobiledevice/idevicerestore) for this that works on Linux/etc.

One notable point of this design is that each installed OS also brings along with it a large subset of system firmware running on coprocessors, as well as the OS loader. This makes it easier to maintain backwards compatibility with older OSes; conversely, it also means the firmware ABI for these coprocessors has no stability guarantees whatsoever.

Terminology note: "OS kernel" here refers to a XNU kernel image, or an equivalent analog. In this section, we use this term to describe anything loaded by iBoot2. When booting third-party OSes, this would normally be a subsequent bootloader stage, such as [m1n1](https://github.com/AsahiLinux/m1n1).

### Boot flow

The platform-mandated boot flow can be summarized as follows:

* SecureROM:
 * Reads/validates iBoot1 from NOR
 * Enters USB DFU mode on failure
* iBoot1:
 * Reads/validates system-global firmware from NOR
 * Bootstraps some coprocessors
 * Shows the Apple logo and plays the boot chime
 * Picks and validates a boot policy
 * Reads/validates iBoot2 from the chosen OS container on NVMe
* iBoot2:
 * Reads/validates OS-paired firmware from NVMe
 * Loads and locks some of that firmware, re-bootstraps display coprocessor
 * Reads/validates the Apple Device Tree from NVMe
 * Reads/validates the OS kernel from NVMe
 * Puts some coprocessors to sleep
 * Jumps to OS kernel

The OS kernel is the first point in the boot flow where we can run non-Apple-signed code.

Notably, at no point in this process is any I/O initialized other than the screen, the speakers, and checking for power button presses or (on laptops) specific keys. There is *no* external storage boot support in the bootloader flow on these machines. Behind the scenes, booting macOS from an external drive involves the moral equivalent of copying `/boot` to internal storage, and only the root/data filesystems truly live on external storage. There is also no boot menu (but keep reading).

### recoveryOS and 1TR

recoveryOS is a macOS image that is used to provide an environment for users to perform recovery and installation tasks on these machines. In addition, it also serves as the boot picker menu on these machines.

recoveryOS can be requested via NVRAM variables on reboot, or can automatically be invoked after a certain number of boot failures. It is a minimal macOS image that presents the user with a recovery menu that allows them to change system security settings, partition disks, launch a web browser, launch a root terminal, reinstall macOS, etc. Network access is supported.

[[https://github.com/AsahiLinux/docs/blob/main/assets/recoveryos.png|alt=recoveryOS]]

In addition, there is a "special" boot flow that grants additional capabilities. When the users powers up the machine by holding down the power button, this loads the recoveryOS paired with the currently active default boot OS volume (falling back to the system one), and first shows a boot picker to allow the user to choose an OS to boot (and optionally make the default):

[[https://github.com/AsahiLinux/docs/blob/main/assets/boot_picker.png|alt=Boot Picker]]

If the user chooses "Options", they will be presented with the recoveryOS menu, as above. When booted this way, it is called "One True recoveryOS" (1TR), and it has additional powers granted to it by SEP (secure enclave) firmware. Additionally, this recoveryOS will be considered "paired" with the OS container it belongs to, and be able to perform specific operations on that OS. In particular, this mode is required in order to install a custom OS kernel.

One consequence of the boot picker being implemented as a macOS application behind the scenes is that is has full accessibility support (including VoiceOver), which is rather unique.

### SEP (Secure Enclave Processor)

The SEP is the Mac's equivalent of a TPM, and is in charge of all security-critical operations such as validating the creation and modification of Boot Policies. It has knowledge of the security state of the system, including whether it is in 1TR, plain recoveryOS, or regular OS boot.

The SEP is used during the boot process, but is put to sleep before the OS kernel is booted. The OS must re-load the SEP firmware and re-bootstrap it to be able to use it (the encrypted firmware blob is provided in a memory region to the OS by iBoot). This means that the SEP is completely optional for a third-party OS, and can be ignored if not needed nor desired.

Useful features provided by the SEP include user authentication, Touch ID, secure key storage / usage, U2F support, etc. For example, it can be used to provide bruteforce-resistant password/touch login and full disk encryption, or to hold SSH keys and require a password or touch to use them.

The SEP is designed to be mutually isolated from the main CPU (AP); neither can compromise the other. It is supposedly also hardened against physical attacks (e.g. glitching and other environmental attacks).

### Security modes, Boot Policies, and machine ownership

Each installed OS on an AS Mac has an associated Boot Policy. The Boot Policy describes the security state of the OS. These Boot Policies are created via the SEP and signed by an internal machine key, so they cannot be modified externally.

The top-level security mode can be in one of three states per OS:

* Full Security
* Reduced Security
* Permissive security

Full Security is the default, and implies that the OS is fully Apple-signed and all security features are enabled. In order to install an OS in Full Security mode, the system must phone home to Apple to validate that the OS is trustworthy (this prevents attackers from installing a known vulnerable, old OS and using it to compromise the system).

Reduced Security allows for certain security features to be disabled, and any Apple-signed OS version to be installed. No phoning home is required to install an OS in this mode, but downgrading or creating a Boot Policy to this mode requires being in recoveryOS and authenticating using machine owner credentials.

Permissive Security allows for ~all security features to be disabled, and third-party kernels to be installed. No phoning home is required. Downgrading to Permissive Security requires booting in 1TR paired to the specific OS involved, and authenticating using machine owner credentials.

The SEP maintains a database of machine owner users. The first such user is created when the user goes through the macOS boot flow on first startup from a factory-fresh state (or after a full DFU wipe). Subsequent machine owners can only be created by authenticating with an existing owner's credentials.

The ability to have a security state per OS is unique to these machines, and allows for things like dual-booting a full-secure macOS (including DRM support, i.e. Netflix in 4K and running iOS apps) and Linux (contrast this to unlocking the bootloader on an Android device or disabling secure boot or changing the signing keys on a UEFI system, which are global operations).

Lower security levels unlock the ability to specify finer-grained security settings in the Boot Policy, such as whether OS boot-args filtering will take place and whether the kernel code will be locked read-only in RAM.

Boot policies can be managed using the `bputil` command from macOS/recoveryOS/1TR (subject to the restrictions of each mode).

### Fully Untrusted OS (fuOS)

fuOS is Apple's term for a third-party OS kernel. In order to configure fuOS boot, an existing OS has to first be downgraded to Permissive Security, and then a custom kernel image can be installed. The image is installed using the `kmutil` command and it will modify the Boot Policy to insert its hash into it, thereby preserving the secure boot chain. iBoot2 will only load this specific fuOS image; replacing or upgrading it requires booting into 1TR and running `kmutil` again. This operation requires machine owner credentials.

Custom kernel images can be flat ARM64 executable images; the entrypoint and (virtual; mostly meaningless) load address are specified when the image is configured. Previously Mach-O binaries were required, but it seems Apple added this feature in 12.1 in order to make life easier for us (as the Mach-O file format requirements changed in that version, breaking our existing tooling).

### ARM64 XNU boot protocol

The boot protocol is fairly simple; there are no bootloader services (e.g. EFI services) or anything of that sort. The OS image is loaded and jumped to by iBoot. The kernel image receives the following information, via various pointer chains:

* Boot-time framebuffer information (incl. verbose boot flag)
* Command line arguments (`boot-args` from NVRAM), filtered by Boot Policy flag
* RAM base/size info
* Apple Device Tree
* SEP firmware blob

Images are always loaded at a randomized offset in low RAM (KASLR), so they must be relocatable. Image text is optionally locked as read-only in the memory controller, for security reasons. In addition, the CPU0 reset vector is locked at a computed offset within the image, so resuming from sleep mode requires code to be present at that address.

### Apple Device Tree

Apple uses a bespoke Device Tree format (simpler than FDT), with a similar data model to the Open Firmware device trees that are standard in embedded Linux/BSD systems. The device tree is built by iBoot2 from a template, system configuration information, and dynamic data. The schema for the device tree is not strictly stable from OS version to OS version, but major changes are rare.

OSes must parse the ADT to extract vital machine- and boot-specific information.

### Firmware overview

Brief overview of known firmware blobs (note: some details here are unverified):

| Name     | Chip     | Description                         | Encrypted | Storage            | Loaded by    | Started by  | Size (approx.)            |
| -------- | -------- | ----------------------------------- | --------- | ------------------ | ---------    | ----------- | ------------------------- | 
| iBoot1   | SoC (AP) | First stage bootloader              | Yes       | NOR                | SecureROM    | SecureROM   | ~600-1000 KB (comp.)
| iBoot2   | SoC (AP) | Second stage bootloader             | Yes       | Preboot            | iBoot1       | iBoot1      | ~450-800 KB (comp.)
| SMC      | SoC\*1   | System Management Controller        | Yes \*2   | Embedded in iBoot1 | iBoot1       | iBoot1      | ~200 KB (comp.)
| PMU      | PMU      | Power Management Unit               | Yes \*2   | Embedded in iBoot1 | iBoot1       | iBoot1      | ~10 KB
| SEP      | SoC      | Secure Enclave Processor            | Yes       | iSC                | iBoot1+OS    | iBoot1+OS   | ~7.5 MB
| ANS      | SoC      | NVMe controller                     | No        | NOR                | iBoot1       | iBoot1+2+OS | ~800 KB (comp.)
| CIO      | SoC      | Type-C/Thunderbolt I/O              | No        | NOR                | iBoot1       | OS          | ~170 KB
| TMU      | SoC      | Thunderbolt related                 | No        | NOR                | iBoot1       | OS          | ~10 KB
| DCP      | SoC      | Display Controller Processor        | No        | NOR & Preboot      | iBoot1+2     | iBoot1+2+OS | ~9.5 MB (~2.5 MB comp.)
| ANE      | SoC      | Apple Neural Engine                 | No        | Preboot            | iBoot2       | OS          | ~5 MB (~180 KB comp.)
| AGX      | SoC      | Apple Graphics (GPU)                | No        | Preboot            | iBoot2       | OS          | ~2.5 MB (~150 KB comp.)
| ISP      | SoC      | Image Signal Processor (Camera) \*3 | No        | Preboot            | iBoot2       | OS          | ~12 MB (~2.5 MB comp.)
| SIO      | SoC      | Smart I/O (UART/I2C/SPI DMA)        | No        | Preboot            | iBoot2       | OS          | ~1 MB (~50 KB comp.)
| AVE      | SoC      | Audio/Video Encoder                 | No        | Preboot            | iBoot2       | OS          | ~1.2 MB (~300 KB comp.)
| AOP      | SoC      | Always-On Processor \*4             | No        | Preboot            | iBoot2       | OS          | ~1.2 MB (~300 KB comp.)
| PMP      | SoC      | Power Measurement Processor         | No        | Preboot            | iBoot2       | OS          | ~400-920 KB (~100 KB comp.)
| AVD      | SoC      | Audio/Video Decoder                 | No        | Embedded in XNU    | OS           | OS          | ~40 KB
| SECDIS   | SECDIS   | Secure Mic/Cam Disable FPGA \*5     | No        | On-chip flash      | Self         | Self        | Not upgradable by design
| IPD      | IPD      | InputDevice (Touchpad/Keyboard) \*5 | No        | Preboot/Flash \*6  | Self         | Self        | ~900 KB (~384 KB comp.)
| MT       | DFR      | Touch Bar (DFR) Multitouch \*7      | No        | Preboot/Flash? \*6 | Self?        | Self?       | ~60 KB
| XHCI     | ASM3142  | PCI xHCI USB controller \*8         | No        | Embedded in XNU    | OS           | OS          | ~128 KB
| WLAN     | WLBT     | Wi-Fi (Broadcom FullMAC)            | No        | OS filesystem      | OS           | OS          | ~1.4 MB (~700 KB comp.)
| BT       | WLBT     | Bluetooth (Broadcom)                | No        | OS filesystem      | OS           | OS          | ~470 KB (~280 KB comp.)
| SE       | SE       | Secure Element                      | Yes       | On-chip flash      | Self         | Self / SEP? | ~4.5 MB
| S5E      | S5E      | NAND (SSD) Controller               | No        | On-chip flash      | On-chip ROM? | ANS         | ~700 KB (~300 KB comp.)
| ACE2     | ACE2     | USB-PD Controller                   | No        | Dedicated flash    | On-chip ROM  | OS?         | ~500 KB (~170 KB comp.)
| TCON     | TCON     | Display Timing Controller \*9       | No        | On-chip flash      | Self         | DCP         | ~1.3 MB (~20 KB comp.)
| DP2HDMI  | MCDP29XX | DisplayPort to HDMI bridge \*10     | No        | Dedicated flash    | Self         | DCP         | ~500 KB (~280 KB comp.)

Notes:

1. "SoC" location means part of the main System-on-Chip; otherwise it is an external chip.
2. These firmwares are implicitly encrypted because they are embedded in iBoot1, but there's no good reason for them to be otherwise.
3. Coprocessor is present but unused on machines without a camera.
4. Terrible name, not actually always-on (not even on when the OS boots).
5. Laptops only
6. Boots from Flash, but firmware lives in Preboot and is upgraded by OS FUD daemon if necessary
7. J293 only (MBP 13" M1)
8. J456 (4-port iMac) only
9. Machines with embedded display only
10. Machines with HDMI port only

Many firmware sizes are compressed (many firmwares have large amounts of padding, making uncompressed sizes not very useful to gauge how much code there is). Where large firmwares are stored uncompressed, compressed sizes are also given for better comparison. The sizes should be taken as a rough guide only.

## OS layout & boot

An OS on an Apple Silicon machine, as seen by Apple's tooling, means a portion of an APFS container partition. As the machines natively support multi-boot, and in order to fit within the security design of the platform (e.g. the SEP should know what OS was booted), we recommend a 1:1 mapping between an installed OS and an OS as seen by the platform.

For third-party OSes, we propose the following GPT partition structure per OS:

1. APFS container partition ("stub macOS") (~2.5GB) with:
 * iBoot2, firmware, XNU kernel, RecoveryOS (all required by the platform)
 * m1n1 + device trees + U-Boot fuOS image
 * ~empty root/data filesystem subvolumes
2. EFI system partition (FAT32) (~512MB):
 * Containing GRUB or an EFI OS loader of choice
3. root/boot/etc. partitions (OS-specific)

Rationale: this arrangement pairs together a third-party OS with an APFS-resident OS as seen by Apple's tooling, and allows users to use the native boot picker (with a11y support). It avoids potential trouble down the road which could come from having multiple OSes attempt to manage the SEP under a shared OS context. It also lets us have independent secure-boot chains for OSes (once that is implemented), with the fuOS image containing the root of trust for subsequent boot stages, bridged to the machine chain of trust by the user with their machine owner credentials during installation.

While it would be possible to share one APFS container between multiple OSes (and even macOS), there isn't much point to this other than saving a small amount of disk space per OS. Using a separate container partition for each installed OS makes it easier to wipe and start over, which would otherwise require a more complicated cleanup process where certain APFS subvolumes are deleted and certain directory trees in others are wiped.

This design, unconventionally, provides an EFI system partition for each installed OS. There are two reasons for this: first, each OS is logically a "container" and includes the EFI implementation itself, so it makes sense to isolate the ESP from that of other OSes. Second, due to the absence of EFI variable runtime services (see below), it would be difficult for multiple co-existing OSes to share an ESP and configure their respective EFI boot entries. Having separate ESPs allows us to just use the default boot path (`\EFI\boot\bootaa64.efi`) and avoid having to persist boot configurations. It also allows the ESP to be directly used as the `/boot` partition for an OS, without having multiple OSes colliding with each other (if desired).

In the future, once open APFS drivers are deemed stable enough to use as a root filesystem, we would like to support full space-sharing coexistence with macOS; at that point only the EFI system partition would be required on top of an existing APFS macOS container.

Due to the presence of multiple ESPs, OSes will need a way to figure out which is theirs. For typical mounts and boot purposes, that can be done with partition/FS IDs; this should mostly be a concern for OS installers which need to determine what ESP to install their bootloader into. For this purpose, we could provide a Device Tree `/chosen` argument containing information about which OS volume was booted by m1n1/U-boot, including the GPT partition GUIDs for the APFS and EFI partitions. This is similar to the way Apple passes this information to macOS in the ADT.

Alternatively, as a hackier but more compatible approach, U-Boot could change the EFI partition GUIDs of all but the currently active OS's ESP to nonstandard ones, so any given OS only ever sees its ESP as the "true" ESP.

### Boot overview

A typical boot of a reference Linux system will go as follows, continuing on from the Boot Flow section above:

* iBoot2 loads the custom kernel, which is a build of m1n1
* m1n1 runs and
 * Parses the Apple Device Tree (ADT) to obtain machine-specific information
 * Performs additional hardware initialization (machine-specific)
  * E.g. memory controller details, USB-C charging, HDMI display (on Mac Mini)
 * Displays its logo on the screen (replacing the Apple logo)
 * Selects an embedded Device Tree (FDT) appropriate for the current platform
 * Personalizes the FDT with dynamic information transplanted from the ADT
 * Loads an embedded U-Boot image and jumps to it
* U-Boot runs and
 * Parses the FDT
 * Initializes the keyboard for input
 * Initializes ANS/NVMe
 * Prompts the user to break into a shell if requested
 * Mounts the appropriate EFI System Partition
 * Brings up basic EFI services
 * Locates the default EFI bootloader in the ESP, e.g. GRUB, and boots it
* GRUB runs and
 * Uses EFI disk access services to mount the /boot filesystem (could be the ESP itself)
 * Locates its configuration file and additional components
 * Presents the user with a boot menu, using EFI console/input services
 * Loads the kernel and initramfs from /boot
 * Jumps to the kernel
* The Linux kernel boots as it would on any other UEFI+FDT platform

This boot chain is designed to progressively bring the system closer to a "typical" ARM64 machine, so that subsequent layers have to worry less about the particulars of Apple Silicon machines.

### m1n1

m1n1 is our first-stage bootstrap for Apple Silicon systems. Its purpose is to bridge between the XNU boot protocol and the Device Tree / ARM64 Linux boot protocol, and do low-level bring-up so that subsequent boot stages do not have to be concerned with it.

m1n1 can also be puppeteered via USB for development and reverse engineering purposes, including loading kernels to allow for a very fast build-test cycle. It also features a bare-metal hypervisor that can boot Linux or macOS and provide a virtualized UART over USB, and includes advanced Python-based event tracing framework. These features are not intended for end users, but we hope they make OS development and testing on these platforms as enjoyable as possible.

### U-Boot

U-Boot's provides the first point of local (keyboard) user interaction, and support for booting from USB or other external devices. It also implements EFI services that hide the specifics of the platform, making it look like a typical UEFI machine.

Notably, U-Boot cannot provide particularly useful EFI runtime services. As the platform does not have an EFI variable store, and it is not practical to e.g. share NVMe access with a running OS, it won't be possible to make modifications to EFI boot configs from a running OS. Instead, those modifications would have to be made by changing configuration files directly. This shouldn't be an issue if different OSes use different ESPs.

### GRUB

GRUB does the final Linux loading and provides users with the familiar kernel selection and option editing menu. GRUB should not need any patches to work on Apple Silicon machines, as it relies entirely on EFI services to do its job. It is up to the OS distribution to decide what to use here; GRUB is merely an example.

## Initial installation

On these these machines, there is a mismatch between the point where a third-party kernel boots (after iBoot2), and the required per-OS boot components (including iBoot2 itself, firmware, and other files, as well as the recoveryOS image and XNU kernel for it). In addition, Apple's tooling requires these files to be laid out in a certain way in the Preboot partition in order to work properly in the OS selection menus, beyond the requirements imposed by iBoot1/2 themselves. In effect, creating a new OS container requires, essentially, installing macOS minus the root filesystem.

Thankfully, all the required components can be fetched from the restore images (IPSW files) which are publicly available at [well-known](https://ipsw.me/), stable URLs. We have implemented a prototype of this process in [asahi-installer](https://github.com/AsahiLinux/asahi-installer), a Python-based installation framework that is intended to run from 1TR. It streams the required bits of the IPSW file, avoiding a complete download, and sets up the partitions and contents as required to boot recoveryOS and subsequently a custom kernel.

We don't expect OSes to want to reinvent this particular wheel (trust us, you don't want to), so we'd like to make the installer flexible enough to support bootstrapping different installation flows.