01 Power and Firmware

The Problem

When you press the power button, the CPU has nothing. No operating system, no programs, nothing in RAM. The processor is a powerful chip that can execute instructions, but it has no instructions to execute. Something has to wake up the hardware, figure out what's connected, and find an operating system to run.

That something is firmware -- code stored on a chip on the motherboard that runs before anything else. The firmware's job is straightforward:

Initialize the hardware (RAM, storage controllers, USB, network)
Find something to boot (a disk, a USB drive, a network server)
Load it into memory and jump to it

Everything after that is the operating system's problem.

This seems simple, but the details matter enormously for security, trust, and remote management. Modern firmware does far more than initialize hardware -- it runs its own mini operating system, enforces signing chains, and on Intel hardware, includes a hidden co-processor that can access your RAM and network even when the computer is "off."

What Actually Happens at Power-On

The First Milliseconds

When power reaches the motherboard, the main CPU doesn't start immediately. Instead, a voltage regulator stabilizes power rails, the clock generator starts producing timing signals, and the chipset (the support chips that connect the CPU to everything else) begins its own initialization.

On Intel systems, the Intel ME wakes up first -- before the CPU. It runs from its own dedicated memory and handles early hardware setup that the CPU cannot do for itself. On AMD systems, the AMD PSP does the equivalent. The main CPU cores are held in reset until these co-processors finish their work.

Only after the management processor has initialized key subsystems does it release the main CPU from reset.

UEFI: The Firmware Standard

Nearly all modern computers use UEFI (Unified Extensible Firmware Interface) as their firmware. UEFI replaced the older BIOS standard in the mid-2000s. Where BIOS was a simple 16-bit real-mode program with severe limitations, UEFI is essentially a small operating system with drivers, applications, and a shell.

UEFI initializes in phases, each one building on the last:

Phase	What It Does
SEC	First code to run. Sets up temporary memory using CPU cache. Root of trust.
PEI	Initializes RAM. Until this completes, only a few KB of cache memory are available.
DXE	Loads drivers for all hardware: USB, storage, GPU, network. Full RAM available.
BDS	Reads boot entries from NVRAM, finds the OS on disk or network. If Secure Boot is enabled, verifies signatures here.
TSL	OS bootloader runs (still in UEFI environment). Loads the kernel.
RT	OS takes over. Only minimal firmware services remain (clock, NVRAM access).

The boot entries in NVRAM (non-volatile memory on the motherboard -- see UEFI for details) are like a priority list: "Try disk first, then USB, then network." Each entry points to a file on the EFI System Partition (ESP) -- a small FAT32 partition that firmware knows how to read. If all entries fail, firmware falls back to a well-known path (\EFI\BOOT\BOOTx64.EFI) on any ESP it finds. This is how USB installers work without any prior configuration.

With Secure Boot enabled, the firmware verifies the signature of every binary it loads during BDS and TSL. An unsigned or wrongly-signed bootloader on a rogue USB stick is rejected -- the firmware refuses to execute it. Without Secure Boot, the firmware runs whatever it finds. FortrOS enables Secure Boot and signs the preboot UKI with the org's CA key. See the Secure Boot section below and the concept page for the full key hierarchy.

The Hidden Processors

This is where it gets uncomfortable -- and then interesting. Every modern x86 CPU has a hidden co-processor that raises real security concerns. But these same processors provide capabilities (remote power control, hardware health monitoring) that a self-healing cluster can use to its advantage. The question isn't just "how do we defend against this?" but "can we take positive ownership?" See How FortrOS Does It below for how the org decides.

Every Intel CPU shipped since 2008 contains the Intel ME -- a separate processor embedded in the chipset, running its own operating system (MINIX 3 on modern chips), with direct access to your RAM and network interface. It operates whenever the system has power, even when the computer is "off" (standby). The main CPU has no visibility into what the ME is doing.

CPUs have nested privilege levels called "rings" -- each ring has total control over the rings above it. Your applications run at Ring 3 (least privileged). The OS kernel is Ring 0. The hypervisor is Ring -1. Firmware is Ring -2. The ME operates at Ring -3: below everything, answering to nothing.

ME is the hardware. On business/enterprise chips (Intel vPro), it runs AMT (Active Management Technology) -- software that provides remote power control, remote desktop, and remote OS reinstallation. AMT is genuinely useful for managing fleets of machines. It's also genuinely concerning as an attack surface.

AMD has an equivalent: the AMD PSP, an ARM processor on the CPU die. It handles platform security (boot integrity, crypto, TPM emulation) but lacks the network stack and remote management features of Intel ME. It's less capable and less concerning, but also less useful for remote management.

The uncomfortable truth is: you cannot fully disable either one. The ME can be reduced to a minimal stub (it completes hardware init, then goes dormant) via tools like me_cleaner or the undocumented HAP bit. The PSP is required for the CPU to boot at all -- it initializes RAM before the x86 cores are released from reset.

Left ignored, the ME runs whatever firmware the vendor shipped -- Intel and the hardware OEM have control, not you. On vPro hardware, AMT may be configured by the OEM or a previous owner with credentials you don't know. Taking positive ownership (provisioning AMT with your own credentials, or neutralizing ME with me_cleaner) is better than leaving it as an unknown actor on your network.

Secure Boot

Secure Boot is a UEFI feature that verifies the signature of everything loaded during boot. The idea is simple: only run code that someone you trust has signed. The implementation uses a certificate hierarchy:

Platform Key (PK) -- The root of trust. Controls who can modify the other keys. Set by the hardware vendor.
Key Exchange Key (KEK) -- Authorized to update the signature databases. Microsoft and the OEM typically have KEKs.
Signature Database (db) -- Certificates and hashes of trusted boot binaries. If a bootloader's signature chains to a cert in db, it runs.
Forbidden Database (dbx) -- Blocklist. Anything matching dbx is rejected, regardless of db.

The chain works like HTTPS certificate validation: firmware checks the bootloader's signature against db, the bootloader checks the kernel's signature against its own embedded key, and so on until the OS is running. If any link breaks, boot stops.

For a custom OS like FortrOS, you have options: enter UEFI Setup Mode and enroll your own keys (you control the chain but must add Microsoft's certs too if you want to dual-boot), use the Microsoft-signed "shim" bootloader (works on any machine out of the box but adds a dependency), or add your certificate to the existing db alongside the vendor's.

How Others Do It

ChromeOS: Replace the Firmware

Google doesn't trust vendor firmware. Chromebooks use coreboot -- an open-source firmware that replaces UEFI entirely. The boot payload is Depthcharge (Google's custom bootloader, not GRUB).

The trust chain starts from a read-only region of the firmware chip, protected by a physical write-protect mechanism on the motherboard. This read-only region contains the root public key and verifies everything above it. If verification fails, the device shows a recovery screen.

Tradeoff: Maximum control and security, but requires hardware partnerships. You can't install ChromeOS's firmware on arbitrary hardware.

Talos Linux: Work With UEFI, Lock It Down

Talos takes a pragmatic approach: use UEFI as-is, but lock down everything above it. Boot images are UKIs (Unified Kernel Images) -- single signed binaries containing the kernel, initramfs, and kernel command line. Since the command line is inside the signed binary, an attacker can't modify boot parameters.

Talos uses two key pairs: one for Secure Boot (enrolled in firmware, verifies the UKI) and one for TPM PCR signing (seals disk encryption keys so they're only released to the correct boot chain). You can use Siderolabs' pre-signed images or build with your own keys.

Tradeoff: Works on commodity hardware with no firmware changes. The vendor firmware is a black box you trust, but everything above it is verified.

NixOS: Flexibility Over Lockdown

NixOS supports both UEFI (systemd-boot) and legacy BIOS (GRUB). Every system rebuild creates a new boot entry, so you can roll back to any previous configuration from the boot menu. The firmware is whatever the vendor ships -- NixOS doesn't attempt to customize or replace it.

Tradeoff: Maximum flexibility and rollback capability. Secure Boot is supported but not the default. The focus is on OS-level reproducibility, not firmware-level security.

The Tradeoffs

Dimension	Replace firmware	Use UEFI + Secure Boot	Ignore firmware
Security	Highest (you control root of trust)	Good (verified chain from firmware)	Lowest (trust vendor blindly)
Hardware support	Narrow (only supported boards)	Broad (anything with UEFI)	Broadest
Complexity	High (maintain firmware)	Moderate (manage signing keys)	Low
ME/PSP control	Can neutralize (coreboot)	Cannot (vendor firmware)	Cannot
Vendor lock-in	None (open source firmware)	Moderate (UEFI spec + vendor quirks)	High

The fundamental tension: the deeper you go, the more secure you are, but the fewer machines you support and the more you have to maintain.

How FortrOS Does It

FortrOS takes a layered approach:

Default: Use UEFI as-is. FortrOS boots from a UKI on the ESP, similar to Talos. This works on any modern hardware with no firmware modifications. Secure Boot is supported -- the org CA signs the preboot UKI, and the signing certificate is enrolled in UEFI.

Intel ME/AMD PSP: Org policy decides. FortrOS detects what management hardware is available and follows the org's configured policy:

Policy	What Happens
`use`	Maintainer provisions AMT/DASH during enrollment. Credentials stored in org state. Remote power, console, and health monitoring available. The org can power-cycle unresponsive nodes without physical access.
`neutralize`	Apply me_cleaner or set HAP bit during provisioning. Document the reduced firmware state. No remote management. For government, opsec, and paranoid deployments.
`ignore`	Don't touch the management engine, don't depend on it. The default for new orgs.

Future: coreboot on supported hardware. For government and high-security deployments, FortrOS can target coreboot-compatible hardware (System76 laptops, certain server boards). This gives full firmware control, including ME neutralization and custom verified boot. This is an additive option -- it doesn't replace the UEFI path, it provides an alternative for hardware that supports it.

Why This Follows From FortrOS's Principles

Works on any hardware (design principle: self-organizing cluster from any collection of machines). UEFI is the pragmatic choice.
Policy-driven security (design principle: ZTNA everywhere). The org decides its own trust posture. A homelab and a government installation have different threat models.
Self-healing (design principle: self-organization is algorithmic). When ME/AMT is available and policy allows, the org can remotely recover unresponsive nodes -- power cycle, force PXE boot, re-provision. No human with a USB stick required.

Stage Boundary

What Firmware Produces

After firmware completes, the system is in this state:

All hardware is initialized (RAM, storage, USB, network, GPU)
The ESP has been found and the boot target (UKI) loaded into memory
If Secure Boot is enabled, the UKI's signature has been verified
UEFI Runtime Services are available (NVRAM access, real-time clock)
Intel ME / AMD PSP are running (unless neutralized)

What Firmware Hands Off

The firmware loads a single binary (the UKI on the ESP) into memory and jumps to it. From firmware's perspective, its job is done. It doesn't know or care that this binary is a FortrOS preboot agent.

What Firmware Does NOT Do

It does not know about FortrOS, the org, encryption, or networking
It does not verify trust beyond Secure Boot (no org-level trust)
It does not configure the network (that's the preboot's job)
It does not unlock encrypted storage (that's the preboot's job)
It does not select which kernel generation to boot (that's the preboot's job)

The next stage -- 02 Finding the OS -- covers how the preboot UKI gets onto the ESP in the first place, and what happens once firmware loads it.