# Pre-OS Trust Boundary ## Identification The security and recovery boundary formed before the installed operating system runs, including firmware, NVRAM, payloads, drivers, and boot policy. ## Notebook evidence - [[Scanned_20260730-1719#PDF page 19 — macOS kernel extensions, storage controllers, and historical dates|PDF page 19: macOS kernel extensions, storage controllers, and historical dates]] — The dates likely come from driver files, certificates, builds, or device metadata rather than the notebook’s writing date. The author is tracing which third-party storage extension attaches to which hardware and framework. - [[Scanned_20260730-1719#PDF page 20 — macOS recovery and command-line tool inventory|PDF page 20: macOS recovery and command-line tool inventory]] — This is a rescue-shell vocabulary sheet: the commands most useful when the graphical system is unavailable or a disk, account, boot state, or network must be diagnosed from Recovery. - [[Scanned_20260730-1719#PDF page 44 — Wineskin, cloud configuration, and Ozmosis|PDF page 44: Wineskin, cloud configuration, and Ozmosis]] — The notebook pivots from contact storage back into compatibility engineering: Windows binaries above macOS through Wine, and macOS boot support below the OS through firmware modules. - [[Scanned_20260730-1719#PDF page 50 — AMI Aptio firmware modules and UEFITool|PDF page 50: AMI Aptio firmware modules and UEFITool]] — The author wants firmware that can understand more filesystems and emulate missing services before an OS loads. This is the architectural center of the Ozmosis section: move compatibility functions into UEFI modules so multiple boot paths can use them. - [[Scanned_20260730-1719#PDF page 53 — Ozmosis build components, PXE, and Kext-to-FFS conversion|PDF page 53: Ozmosis build components, PXE, and Kext-to-FFS conversion]] — The intended firmware is not merely “Mac compatible.” It is a universal pre-OS service layer capable of local filesystem access, Mac identity support, shell access, and network boot. - [[Scanned_20260730-1719#PDF page 67 — MacBookAir7,2 boot security and kernel memory features|PDF page 67: MacBookAir7,2 boot security and kernel memory features]] — The page is a Linux-on-Mac boot inventory: exact model/firmware, certificate trust, memory pressure behavior, mandatory-access-control frameworks, filesystem layer, relocation, and legacy disk compatibility. - [[Scanned_20260730-1719#PDF page 75 — Coreboot/Libreboot summary and supported operating systems|PDF page 75: Coreboot/Libreboot summary and supported operating systems]] — This is the notebook’s capstone. Everything previously collected—serial access, IOMMU, USB, SPI, iPXE, alternate OSes, encryption, Tor/Tails, open drivers, and vendor-independent recovery—is gathered beneath open firmware. “The Federation” is the proposed architecture: a common pre-OS substrate that can host multiple independently governed operating environments. ## Relationships and overlays The source places this note in a shared evidence cluster with [[Accusys|Accusys]] · [[Advanced Configuration and Power Interface|Advanced Configuration and Power Interface]] · [[Btrfs|Btrfs]] · [[exFAT|exFAT]] · [[Extended Verification Module|Extended Verification Module]] · [[FakeSMC|FakeSMC]] · [[HighPoint Technologies|HighPoint Technologies]] · [[Kernel Extension|Kernel Extension]] · [[Libreboot|Libreboot]] · [[macOS Recovery|macOS Recovery]] · [[NVRAM|NVRAM]] · [[Ozmosis firmware|Ozmosis firmware]] · [[Preboot Execution Environment|Preboot Execution Environment]] · [[Scanned_20260730-1706|Scanned_20260730-1706]] · [[System Management Controller|System Management Controller]] · [[Virtual File System|Virtual File System]] · [[Wineskin|Wineskin]]. Within the larger collection, this evidence extends [[Vendor-Agnostic Recovery|vendor-agnostic recovery]] and [[Continuity Architecture|continuity architecture]] by showing how software, hardware, identity, and pre-OS control depend on recoverable interfaces. ## Evidentiary status and open leads Capture `kextstat`, bundle identifiers, code-signing data, and hardware PCI IDs together to distinguish installed, loaded, and merely present extensions. ## Source - [[Scanned_20260730-1719|Scanned_20260730-1719]]