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 withDocumentation 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.
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 onEnvironment.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.
EfiExecutableInfoand volume name path resolution require Windows 8 or later. - Linux with the
efivarfsorefivarsfilesystem 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.