Skip to content
Snigdha OSDecentralized

Boot Process & Verification

Unified Kernel Images (UKIs), systemd-stub, and early initramfs initialization.

5 min readUpdated: 2026-11-12

Snigdha OS Decentralized — UEFI Secure Boot Architecture

1. Overview & Trust Philosophy

UEFI Secure Boot is a cryptographic gatekeeping mechanism implemented in system firmware that ensures only authenticated bootloaders and operating system kernels can execute on the hardware.

In Snigdha OS Decentralized, Secure Boot is not treated as a mere branding badge or isolated executable signature. It is the cryptographic root of trust for the entire operating system, anchoring the hardware execution directly to an immutable, cryptographically verified operating system image.

+-------------------------------------------------------------+
|                     UEFI Firmware                           |
|       (Platform Key [PK] -> Key Exchange Key [KEK])         |
+-------------------------------------------------------------+
                              |
                              v
+-------------------------------------------------------------+
|               Signature Database (db / dbx)                 |
|             Snigdha OS db Certificate Enrolled              |
+-------------------------------------------------------------+
                              |  Authenticode Verification
                              v
+-------------------------------------------------------------+
|              Signed Unified Kernel Image (UKI)              |
|                     (systemd-stub PE32+)                    |
|  +-------------------------------------------------------+  |
|  | .sbat     | SBAT Metadata                             |  |
|  | .osrel    | Distribution Release Identifier           |  |
|  | .cmdline  | Authenticated Command Line & Root Hash    |  |
|  | .linux    | Linux Hardened Kernel Binary              |  |
|  | .initrd   | Amnesic Initramfs & dm-verity Hook        |  |
|  +-------------------------------------------------------+  |
+-------------------------------------------------------------+
                              |  Handover & Execution
                              v
+-------------------------------------------------------------+
|               Kernel Lockdown (Integrity Mode)              |
|         Enforces BPF, kexec, and module signing gates       |
+-------------------------------------------------------------+
                              |  Initramfs Mount Hook
                              v
+-------------------------------------------------------------+
|                 dm-verity Authentication                     |
|           Merkle Hash Tree -> Verified Root Device          |
+-------------------------------------------------------------+
                              |  Lowerdir
                              v
+-------------------------------------------------------------+
|                  Snigdha Amnesia OverlayFS                  |
|          (Verified Lowerdir + Volatile RAM Upperdir)        |
+-------------------------------------------------------------+

2. Firmware Trust Hierarchy: PK, KEK, db, and dbx

UEFI Secure Boot architecture relies on a four-tier variable database maintained in non-volatile motherboard NVRAM:

  1. Platform Key (PK):

    • The master key of the platform, owned by the hardware administrator or OEM.
    • Controls access to the Key Exchange Key (KEK) database.
    • When PK is present, firmware operates in User Mode. When PK is cleared, firmware enters Setup Mode, allowing unrestricted key enrollment.

  2. Key Exchange Key (KEK):

    • Authorizes modifications to the Signature Database (db) and Forbidden Signature Database (dbx).
    • Enables trust delegation between hardware manufacturers and operating system vendors without replacing the PK.

  3. Signature Database (db):

    • Contains authorized X.509 certificates and SHA-256 binary hashes.
    • Firmware validates every EFI executable (.efi) against db before execution.
    • Snigdha OS enrolls its designated db certificate to authorize the Snigdha Unified Kernel Image (UKI).

  4. Forbidden Signature Database (dbx):

    • Revocation blacklist containing revoked binary hashes and compromised certificates.
    • Firmware immediately terminates boot if an EFI executable matches any dbx entry.

3. Unified Kernel Images (UKIs)

Traditional Linux UEFI boot architectures load an external bootloader (such as GRUB or systemd-boot), which subsequently reads an unsigned kernel image, unsigned initramfs, and mutable configuration file (grub.cfg) from an unauthenticated filesystem. This introduces a major security boundary flaw: an attacker with local or USB access can modify kernel parameters (e.g. bypassing Amnesia, disabling NetGuard, or setting init=/bin/sh).

Snigdha OS Decentralized resolves this vulnerability by adopting Unified Kernel Images (UKIs) adhering to the UAPI UKI Specification.

A UKI is a single, self-contained PE32+ UEFI executable built on systemd-stub:

  • .linux: The linux-hardened kernel binary.
  • .initrd: The complete early-boot ramdisk containing the volatile Amnesia and dm-verity mounting infrastructure.
  • .cmdline: The security-critical kernel command line containing all memory erasure parameters (init_on_free=1), storage isolation (systemd.gpt_auto=0), AppArmor enforcement, and the authenticated dm-verity root hash and salt.
  • .osrel: The official /etc/os-release distribution metadata.
  • .sbat: Secure Boot Advanced Targeting (SBAT) metadata for revoking vulnerable boot components without invalidating certificates.

Because the entire UKI is signed as a single PE executable using sbsign, modifying a single byte of the kernel, initramfs, command line, or metadata invalidates the Authenticode signature, causing firmware to halt immediately.

4. User-Managed Key Enrollment & Dual-Boot Safety

Snigdha OS strictly complies with the following engineering principles:

  1. No Automatic Firmware Mutation: Snigdha OS will never silently execute sbctl enroll-keys or mutate motherboard NVRAM variables during build, boot, or installation.
  2. Preservation of Existing OEM & Microsoft Keys: Most user hardware requires OEM certificates to initialize PCIe graphics option ROMs (e.g. Nvidia/AMD GPU display firmware) and allow dual-booting existing operating systems. Snigdha OS provides a hybrid enrollment mode that appends Snigdha certificates while preserving third-party keys.
  3. Explicit User Consent: Enrollment is governed exclusively through the user-controlled CLI utility snigdha-enroll-keys.

Safe Enrollment Workflow 

# 1. Inspect current firmware status (Setup Mode vs User Mode)
snigdha-enroll-keys --status

# 2. Back up existing NVRAM variables to encrypted or safe storage
snigdha-enroll-keys --backup /path/to/backup/

# 3. Enroll Snigdha keys in Setup Mode (Hybrid Mode preserves OEM ROMs)
snigdha-enroll-keys --enroll-with-microsoft

5. Legacy BIOS Boot & Fallback Compatibility

Snigdha OS Decentralized preserves conventional BIOS El Torito boot capability using Syslinux and GRUB.

However, distribution policy mandates absolute transparency:

  • Conventional BIOS firmware does not provide cryptographic Secure Boot protection.
  • When booted under BIOS, Snigdha Security Center and snigdha-boot-status report: Boot Mode: BIOS | Secure Boot: NOT_APPLICABLE | dm-verity: NOT_APPLICABLE
  • Amnesia, NetGuard, AppArmor, and user-space protections remain fully active on BIOS systems, but hardware-anchored boot integrity is truthfully classified as unavailable.