- Generated by
1.18.0
Platform backend behavior and supported file layouts.
lazybiosCTXNew selects a lazybiosBackend_t value from the target platform. Applications may inspect ctx->backend before calling lazybiosInit. Backend selection affects only host loading — that is, lazybiosInit called with two NULL paths. The file modes described in Separate entry point and DMI files and Merged file are deterministic and behave identically regardless of which backend the build selected. LAZYBIOS_BACKEND_UNKNOWN remains the no-backend sentinel, while LAZYBIOS_BACKEND_GENERIC identifies an active generic fallback on an otherwise unrecognized target.
Native host acquisition is kept in one source file per platform under src/backends/. Shared validation, conversion, and the common legacy physical-memory reader used by Haiku, BeOS, QNX Neutrino, MINIX 3, and the generic backend live in src/backend.c, while src/lazybios.c selects and dispatches the active backend. The physical-memory portion of src/backend.c is compiled only for those targets.
The Linux backend first reads the entry point and DMI table from sysfs. If the DMI sysfs table cannot be opened, it looks in /sys/firmware/efi/systab for an SMBIOS3= or SMBIOS= physical address and uses that address as the start of its /dev/mem search. If no usable EFI address is available, the search begins at the legacy 0xF0000 firmware window.
The physical-memory path scans a 64 KiB region on 16-byte boundaries. Invalid, truncated, or checksum-failing candidates are skipped while the scan continues for a valid SMBIOS entry point. After validation, the backend maps the structure-table address and length reported by that entry point. Access to physical memory can require elevated operating-system permissions.
The default sysfs paths are exposed as LINUX_SYSFS_SMBIOS_ENTRY and LINUX_SYSFS_DMI_TABLE. The physical-memory device path is exposed as DEV_MEM.
The Windows backend obtains the DMI table with GetSystemFirmwareTable. That API does not provide the physical table address or a raw entry point, so lazybios constructs a compatible entry point from the returned version and table metadata. Consumers must not treat the generated table address as a physical address.
The macOS backend locates the AppleSMBIOS service in the I/O Registry. It reads the raw SMBIOS entry point from the SMBIOS-EPS property and the DMI structure table from the SMBIOS property. The implementation uses IOKit and CoreFoundation and supports both the current I/O Kit main port API and the legacy API used when targeting macOS releases older than 12.0.
The OpenBSD backend looks for the SMBIOS address reported in /var/run/dmesg.boot. When it finds a usable address, the /dev/mem scan starts there; otherwise it falls back to the legacy 0xF0000 firmware window. The 64 KiB search validates candidates on 16-byte boundaries and then maps the structure-table address reported by the selected entry point.
Reading /dev/mem depends on account privileges and the OpenBSD securelevel and memory-access policy.
This backend also serves the FreeBSD derivatives. Backend selection keys on the operating-system name the kernel reports, which comes from TYPE= in sys/conf/newvers.sh. MidnightBSD is the only fork that changes it, so it is matched by name during selection. GhostBSD, HardenedBSD, TrueNAS CORE, pfSense, OPNsense, and CheriBSD all keep the FreeBSD identity and select this backend with no entry of their own.
A fork is therefore supported by default. One needs an explicit entry only if it renames itself the way MidnightBSD does.
The FreeBSD backend requests hint.smbios.0.mem through kenv(2) and uses its value as the start of the /dev/mem search. If the kernel environment value is unavailable or invalid, it falls back to the legacy 0xF0000 firmware window. It scans a 64 KiB region on 16-byte boundaries, validates the entry point, and maps the physical structure table described by it.
Reading /dev/mem depends on account privileges and the FreeBSD securelevel and memory-access policy.
The DragonFly BSD backend requests hint.smbios.0.mem through kenv(2) and uses the returned physical address as the start of its /dev/mem search. If the value is unavailable or invalid, the search starts at the legacy 0xF0000 firmware window.
The backend scans a 64 KiB region on 16-byte boundaries, validates each entry-point candidate, and maps the physical structure-table address and length reported by the selected entry point. Reading /dev/mem remains subject to DragonFly BSD device permissions and physical-memory access policy.
The NetBSD backend obtains the physical SMBIOS entry-point address from the read-only machdep.smbios sysctl. It first uses that address with /dev/smbios, a restricted, read-only aperture into the SMBIOS entry point and structure table. /dev/smbios is address-based: it must be read at the physical entry-point and table offsets and is not a flat file containing the two buffers back-to-back.
If /dev/smbios is unavailable or cannot provide the data, the backend reads the same physical addresses through /dev/mem. On x86, an unavailable sysctl or failed address-based read is followed by a scan of the legacy 0xF0000 firmware window. Entry-point candidates are checksum-validated before their table addresses are used.
Device access remains subject to NetBSD device-node permissions and physical-memory access policy. The sysctl is an address source; it does not expose the complete SMBIOS structure table itself.
The SunOS backend, used on Solaris and illumos systems, first reads /dev/smbios. This device exposes a snapshot containing the SMBIOS entry point and structure table. Its entry point uses the structure-table address as a file-relative offset and can align the table after padding rather than placing it immediately after the declared entry-point length. The single-file loader validates that the complete advertised range fits inside the device image before using that offset.
If /dev/smbios cannot be loaded, the backend scans the legacy 0xF0000 firmware window through /dev/mem. Candidates are checked on 16-byte boundaries before the physical structure-table range described by the selected entry point is mapped.
Access to /dev/smbios or /dev/mem remains subject to the device-node and physical-memory permissions configured by the operating system.
The Haiku backend tries /dev/misc/mem first and /dev/mem second. It searches the legacy x86 firmware window from 0xF0000 through 0xFFFFF on 16-byte boundaries, validates the selected entry point, and then reads the physical structure-table range described by it.
Physical ranges are first accessed with a page-aligned, read-only mapping. If the device cannot be mapped, the loader retries with pread; systems without working positional reads receive a final lseek plus read fallback. Both the entry point and table are committed to the context only after the complete pair has been read and validated.
This backend currently covers only systems whose SMBIOS entry point remains discoverable in the legacy x86 window. In particular, it does not consume the SMBIOS 2.x or 3.x entry-point addresses that Haiku's kernel can receive from boot data. Physical-memory access requires the permissions enforced by Haiku's memory driver.
The BeOS backend tries /dev/misc/mem and then /dev/mem. Like the Haiku backend, it scans only the legacy x86 firmware window and reads the physical table address advertised by the selected entry point. It therefore does not provide a portable acquisition path for non-x86 systems or firmware that publishes SMBIOS only through a modern firmware interface. It shares the Haiku mapping, positional-read, validation, and cleanup behavior.
The ReactOS backend obtains the DMI table using the Win32 GetSystemFirmwareTable API. It operates similarly to the Windows backend, constructing a compatible entry point from the returned table metadata.
The QNX backend maps physical memory directly with mmap_device_memory(), which QNX documents as the interface for this purpose and which wraps mmap with MAP_PHYS and NOFD. No device node is involved, so the backend does not depend on /dev/mem being enabled. It reads the legacy x86 firmware window from 0xF0000 through 0xFFFFF, validates the selected entry point, and then maps the physical structure-table range described by it. Each mapping is page-aligned and released with munmap_device_memory().
Mapping physical memory requires the PROCMGR_AID_MEM_PHYS ability. A process without it fails at the first mapping and the backend falls back to the shared legacy /dev/mem reader, which retries with mmap, then pread, then lseek plus read.
Only x86 targets attempt either path. QNX also runs on AArch64, where no legacy firmware window exists; those builds report the missing window instead of scanning an address range that cannot hold an entry point.
The MINIX backend reads the legacy x86 firmware window through /dev/mem and shares the Haiku and BeOS mapping, positional-read, validation, and cleanup behavior. MINIX exposes physical memory through its memory driver, so access is subject to the permissions that driver enforces.
Like the other legacy-window backends, it does not consume an SMBIOS entry-point address published only through a modern firmware interface, and it fails cleanly on non-x86 targets.
The generic backend is selected as LAZYBIOS_BACKEND_GENERIC for otherwise unrecognized, POSIX-like x86 targets that expose physical memory through /dev/mem or /dev/misc/mem. It performs the same mapping and positional-read fallbacks as the Haiku and BeOS backends. That assumption is not valid for every unknown operating system or architecture, so this option on unrecognized targets.
lazybiosInit(ctx, entry_path, dmi_path) expects one raw SMBIOS entry point file and one raw DMI structure-table file. This layout corresponds to the two Linux sysfs files, so a table captured from /sys/firmware/dmi/tables/ can be replayed as-is. The context owns copies of both file contents through lazybiosDMI_t.
lazybiosInit(ctx, NULL, bin_path) expects the SMBIOS entry point at offset zero of a single file. It accepts both a tightly concatenated entry-point-plus-table dump and an image whose entry point contains a valid file-relative table offset, including SunOS (Solaris/illumos) /dev/smbios snapshots that align the table with padding. The advertised offset and table length must describe a complete range inside the file. Otherwise, the loader treats the bytes immediately following the entry point as the table, preserving support for dumps that retain a physical firmware address.
Whichever mode succeeded, lazybiosInit finishes by building the per-type index described in Type index, so every loading path arrives at the parsers with the same cache in place. A table it cannot index leaves index_valid clear and the parsers walk it directly; the parsed results are the same either way.
lazybiosInit returns 0 on success and -1 on invalid input, I/O failure, allocation failure, unsupported backend, or invalid entry-point data. It also rejects an entry-point path given without a table path, since the entry point alone describes nothing to parse. A failed load must not be followed by a structure getter. Release the context with lazybiosCleanup before returning or attempting a fresh lifecycle.
1.18.0