Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/Rikitav/Unified.Firmware/llms.txt

Use this file to discover all available pages before exploring further.

Unified.Firmware is a .NET Standard 2.1 class library that gives .NET developers a strongly-typed, cross-platform API for interacting with UEFI firmware. Working directly with UEFI NVRAM variables, boot entries, and the EFI System Partition normally requires low-level platform calls, undocumented Win32 APIs, or raw Linux sysfs file manipulation — all of which vary by operating system and demand elevated privileges. Unified.Firmware wraps those details behind a clean, object-oriented surface: read and write boot entries with FirmwareBootService, inspect or mutate global firmware environment variables through FirmwareEnvironment, and locate the EFI System Partition via FirmwareInterface.SystemPartition. The library is aimed at OS installers, bootloader tools, recovery utilities, and any .NET application that needs reliable, programmatic access to UEFI configuration on both Windows and Linux hosts.

Key Features

Boot Entry Management

Create, read, update, and delete UEFI Boot#### variables with FirmwareBootService. Control boot order, set one-time next boot targets, and iterate entries with full type safety.

Firmware Environment Variables

Read and write typed UEFI NVRAM variables through FirmwareEnvironment. Supports string, struct, and array variables with vendor-namespaced GUID isolation.

EFI System Partition Access

Resolve the EFI System Partition to a DirectoryInfo via FirmwareInterface.SystemPartition — no manual MountVol juggling or partition scanning required.

Cross-Platform Backend

The IFirmwareBackend abstraction selects Win32PlatformBackend on Windows and LinuxPlatfromBackend on Linux automatically through FirmwareInterface.CurrentBackend.

Device Path Protocols

Model UEFI device paths with typed protocol classes derived from DevicePathProtocolBase. Hardware and media protocol packages ship separately so you only reference what you need.

EFI Executable Inspection

Inspect EFI PE/COFF executables on Windows 8 and later using EfiExecutableInfo and volume name path resolution built into the Windows backend.

Package Structure

Unified.Firmware is split into focused NuGet packages so applications can take only what they need. Unified.Firmware is the core package. It contains FirmwareInterface (the static entry point), FirmwareEnvironment (NVRAM variable read/write), GlobalFirmwareEnvironment (well-known global variables such as BootCurrent, BootOrder, and OsIndications), EfiPartition (EFI System Partition resolution), and the IFirmwareBackend interface together with its two platform implementations: Win32PlatformBackend for Windows and LinuxPlatfromBackend for Linux. Unified.Firmware.BootService depends on the core package and adds all boot-entry functionality: FirmwareBootService (static CRUD operations), FirmwareBootOption (the concrete load option type), LoadOptionBase (base class for custom option types), LoadOptionAttributes (flag enum for ACTIVE, HIDDEN, CATEGORY_BOOT, etc.), and DevicePathProtocolBase (abstract base for device path protocol implementations). Unified.Firmware.DevicePathProtocols.Hardware provides hardware device path protocol implementations: PciProtocol, MemoryMappedProtocol, ControllerProtocol, and VendorProtocol. Reference this package when your boot entries target PCI or memory-mapped hardware devices. Unified.Firmware.DevicePathProtocols.Media provides media device path protocol implementations: HardDriveProtocol, FilePathProtocol, CdRomProtocol, and VendorDefinedProtocol. Most OS boot entries require at minimum a HardDriveProtocol (partition GUID) and a FilePathProtocol (path to the .efi executable).

Platform Support

Unified.Firmware selects the appropriate backend automatically based on Environment.OSVersion.Platform. Windows uses Win32PlatformBackend, which calls the Win32 GetFirmwareEnvironmentVariable and SetFirmwareEnvironmentVariable APIs. Writing to NVRAM requires the process to hold the SE_SYSTEM_ENVIRONMENT_NAME privilege, which in practice means running as an Administrator. EFI System Partition resolution is performed through IOCTL volume enumeration. Linux uses LinuxPlatfromBackend, which reads and writes variables through the /sys/firmware/efi/efivars (and /sys/firmware/efi/vars) sysfs interface. NVRAM access requires either root or the CAP_SYS_ADMIN capability. UEFI availability is detected by checking for the existence of the /sys/firmware/efi/efivars directory; if it is absent, the system is considered to be booted in Legacy BIOS mode. Any other platform value causes FirmwareInterface.CurrentBackend to throw PlatformNotSupportedException.

Requirements

  • .NET Standard 2.1 or any compatible runtime: .NET 5, .NET 6, .NET 7, .NET 8, or later.
  • Windows (any UEFI-capable version) for general functionality. EfiExecutableInfo and volume name path resolution require Windows 8 or later.
  • Linux with the efivarfs or efivars filesystem mounted (present on all modern EFI-booted distributions by default).
Most write operations — including creating or modifying boot entries and setting firmware environment variables — require elevated privileges. On Windows this means running the process as Administrator; on Linux it means running as root or granting the process CAP_SYS_ADMIN. Read operations on some variables may succeed without elevation depending on the platform, but it is safest to always run firmware tools with appropriate privileges.

Build docs developers (and LLMs) love