SMBIOS Explained: Structure Parsing and UEFI Access

SMBIOS Explained: Structure Parsing and UEFI Access

How does an operating system identify a computer’s motherboard, processor, memory configuration, BIOS version, and system serial number without opening the case or entering firmware setup?

Much of this information is exposed through SMBIOS (System Management BIOS). Firmware publishes a standardized collection of structures describing the system and its components. Operating systems and management utilities can then read those structures to inventory hardware and firmware.

This guide covers the relationship between SMBIOS and DMI, the legacy entry-point discovery process, the layout of SMBIOS structures, and practical access through UEFI. It also includes a UEFI C example and highlights implementation details that matter when writing a reliable parser.

🧩 What Is SMBIOS?

#

SMBIOS is a system-information specification maintained by the Distributed Management Task Force (DMTF). It defines standardized data structures that firmware uses to describe a computer’s hardware and firmware configuration.

DMI (Desktop Management Interface) is the management interface historically associated with this system-information model. The terms SMBIOS and DMI are often used together, but they are not interchangeable: SMBIOS defines the structures and entry-point formats, while DMI describes the management interface and its historical ecosystem.

An SMBIOS table can contain information about:

• System manufacturer, product name, serial number, and UUID.
• BIOS vendor, version, and release date.
• Motherboard manufacturer, product, and revision.
• Processor model and capabilities.
• Memory arrays and individual memory devices.
• Chassis information and asset tags.
• Expansion slots and onboard devices.

The operating system can expose this information through higher-level interfaces. For example, Windows provides selected system information through WMI, while Linux tools such as dmidecode decode SMBIOS structures.

SMBIOS is particularly useful for asset inventory, firmware diagnostics, hardware management, and data-center administration.

1.1 The Role of DMI

#

DMI provides a standardized way for management software to obtain system information without depending on vendor-specific firmware interfaces.

Historically, DMI included a management information format database (MIF database) and mechanisms for management applications to access and maintain inventory information. Some asset-management fields, such as asset tags, can be configured by administrators rather than discovered directly from hardware.

In modern systems, the SMBIOS table is the primary standardized source for much of this firmware-provided inventory data.

A few practical examples include:

• Windows: WMI classes such as Win32_BIOS, Win32_ComputerSystem, and Win32_BaseBoard.
• Linux: dmidecode, which decodes SMBIOS structures.
• Firmware development: UEFI applications and drivers can locate the SMBIOS table through the EFI System Table.
• Data-center operations: Inventory systems can collect manufacturer, product, serial-number, and memory information across large server fleets.

One important distinction: SMBIOS data is supplied by platform firmware. It is not guaranteed to be complete, accurate, unique, or cryptographically authenticated. Management software should treat it as inventory metadata rather than proof of hardware identity.

🔍 Two Historical Methods of Accessing SMBIOS

#

The SMBIOS specification has defined different mechanisms for locating and accessing system-information structures.

The Plug and Play function interface is obsolete for modern development. Table-based access is the relevant approach for current systems.

There are two important entry-point formats:

• SMBIOS 2.x EPS: Uses the _SM_ anchor and the intermediate _DMI_ anchor.
• SMBIOS 3.x EPS: Uses the _SM3_ anchor and supports a 64-bit table address and a maximum table size.

The distinction matters when writing a parser. A modern implementation should check for SMBIOS 3.x as well as the legacy 2.x entry point rather than assuming every system exposes only the older format.

🧭 Finding the SMBIOS Entry Point in Legacy BIOS

#

In a traditional BIOS environment, software can locate the SMBIOS 2.x Entry Point Structure by scanning the BIOS-mapped physical-memory region.

The conventional search range is:

0xF0000 - 0xFFFFF

This is a 64KB region near the top of the first megabyte of physical address space.

3.1 Searching for the _SM_ Anchor

#

The SMBIOS 2.x EPS begins with the five-byte anchor string:

"_SM_"

A basic discovery procedure is:

1. Scan the specified physical-memory range for the _SM_ signature.
2. Check whether the candidate EPS has a valid length and checksum.
3. Verify that the intermediate anchor _DMI_ appears at offset 0x10.
4. Validate the intermediate checksum.
5. Read the table address and table length from the validated EPS.

The _DMI_ signature is located 16 bytes after the beginning of the SMBIOS 2.x EPS.

Implementation note: Finding _SM_ alone is not sufficient. A memory region can contain coincidental occurrences of the same byte sequence. Validate the candidate’s length, checksums, and intermediate anchor before trusting its fields.

3.2 Example Memory Search

#

Suppose a memory inspection tool finds a candidate at:

F000:A670

The candidate begins with:

5F 53 4D 5F

These bytes represent _SM_.

At offset 0x10, the expected intermediate anchor is:

5F 44 4D 49 5F

This represents _DMI_.

A sample SMBIOS 2.4 entry point might report:

• Major version: 02
• Minor version: 04
• Table length: 0x0541 bytes
• Table physical address: 0x000FC980
• Number of structures: 27

The example address and values are specific to the inspected machine. They should not be assumed to apply to other systems.

📋 SMBIOS 2.x Entry Point Structure

#

The SMBIOS 2.x EPS is 31 bytes long in the standard layout. It contains the signature, version information, checksums, and location metadata needed to find the SMBIOS structure table.

The two checksums serve different purposes:

• The primary checksum validates the complete EPS.
• The intermediate checksum validates the intermediate entry-point region beginning at _DMI_.

A valid checksum is obtained when the sum of the covered bytes, calculated modulo 256, equals zero.

The fields most commonly needed for locating the table are:

• 0x16: SMBIOS structure table length.
• 0x18: SMBIOS structure table physical address.
• 0x1C: Number of SMBIOS structures.

The structure count is useful for validating traversal, but the table’s byte length must also be respected. A robust parser should never rely on the count alone.

🗂️ SMBIOS Data Table: How Structures Are Organized

#

The EPS describes where the SMBIOS data table is located. The actual system information is stored in that table as a sequence of structures.

Each structure begins with a common four-byte header.

5.1 Common Structure Header

#

The header is followed by two logical regions:

Formatted section

Contains the fixed-layout fields defined for the particular structure type. Its size is specified by the Length field in the header.

String section

Contains zero or more strings associated with the structure. These strings are stored after the formatted section and are referenced by one-byte string indices in the formatted fields.

The string section ends with a double-null sequence:

00 00

The first null terminates the final string. The second null marks the end of the structure.

A structure with no strings still has the terminating double-null sequence immediately after its formatted section.

5.2 Correct Structure Traversal

#

The next structure does not necessarily begin at a fixed offset because the string section has variable length.

A parser must:

1. Read the structure header.
2. Validate that the formatted length is at least the size of the common header.
3. Advance by the formatted length.
4. Scan for the double-null string-set terminator.
5. Advance past both null bytes.
6. Repeat until the table boundary or Type 127 end-of-table structure is reached.

Conceptually:

Next structure =
    Current structure
    + Formatted section length
    + String section bytes
    + 2-byte terminator

The parser must check the table boundary before every read and scan. Unchecked pointer arithmetic can cause out-of-bounds memory access when firmware publishes malformed or truncated data.

5.3 Common SMBIOS Structure Types

#

The specification defines many structure types. The following are frequently encountered during hardware inventory and firmware analysis.

Types 16, 17, and 19 are particularly useful when examining installed memory. Type 16 describes the memory array, Type 17 describes individual memory devices, and Type 19 describes mapped address ranges.

🧪 Parsing Type 0: BIOS Information

#

Type 0 describes BIOS or system firmware information. It is a useful example because it demonstrates how formatted fields reference strings stored later in the same structure.

6.1 Type 0 Formatted Fields

#

The common header occupies the first four bytes. Type 0 then defines fields such as the vendor string index, BIOS version string index, release date string index, and BIOS characteristics.

The exact formatted length depends on the SMBIOS version and the fields implemented by the firmware. A parser should use the structure’s Length field and check the relevant version and field availability rather than assuming one fixed size.

6.2 String Indices Are Not String Values

#

Fields such as Vendor, BIOS Version, and BIOS Release Date do not contain the actual text.

Instead, each field contains an index into the structure’s string section.

For example:

• 01 refers to the first string.
• 02 refers to the second string.
• 03 refers to the third string.
• 00 means that no string is specified.

A sample Type 0 structure might reference:

The parser must resolve each index by walking the null-terminated strings in order. It must also handle invalid indices and empty string sets safely.

6.3 Example Memory Dump Interpretation

#

Assume the SMBIOS 2.x EPS points to the following table address:

0x000FC980

A memory dump at that location might begin with:

After the formatted fields, the string section contains the vendor, version, and date strings, each terminated by a null byte. The final double-null marks the end of Type 0.

The next structure begins immediately afterward. It may be Type 1 (System Information), followed by Type 2 (Baseboard Information), Type 3 (System Enclosure), and other structures.

In a sample system, these records might identify an AMI BIOS, an MSI MS-7277 motherboard, and a BIOS release date of August 11, 2006.

The values above illustrate how a dump can be interpreted; actual field offsets and structure lengths should always be checked against the SMBIOS version and the structure’s own length field.

🧭 Accessing SMBIOS Through UEFI

#

Legacy BIOS software may need to search physical memory for the SMBIOS entry point. UEFI provides a more direct mechanism.

The UEFI System Table contains a ConfigurationTable array. Each entry associates a GUID with a vendor-specific system table.

SMBIOS entry points are published through standardized GUIDs.

In EDK2, the corresponding GUID symbols are commonly available as:

gEfiSmbiosTableGuid
gEfiSmbios3TableGuid

The first points to the SMBIOS 2.x entry-point structure. The second points to the SMBIOS 3.x entry-point structure.

A modern UEFI application should check both entries. SMBIOS 3.x uses a different entry-point layout and a 64-bit table address, so it must not be interpreted as an SMBIOS 2.x EPS.

7.1 SMBIOS 2.x and 3.x Differences

#

This distinction affects table traversal. For SMBIOS 2.x, the EPS provides a table length and structure count. For SMBIOS 3.x, the parser uses the 64-bit table address and maximum table size, and should stop at the Type 127 end-of-table structure or the specified boundary.

💻 UEFI C Example: Locating and Traversing SMBIOS 2.x

#

The following EDK2-style example demonstrates how to locate the SMBIOS 2.x EPS through the UEFI Configuration Table and traverse its structures.

It is intended as a learning example. Production code should also validate EPS checksums, confirm all pointers and lengths are within accessible memory, and support SMBIOS 3.x where required.

#include <Uefi.h>

#include <Library/UefiLib.h>
#include <Library/BaseMemoryLib.h>
#include <Guid/SmBios.h>

EFI_STATUS
ReadSmbios2Table (
  IN EFI_SYSTEM_TABLE *SystemTable
  )
{
  UINTN                    Index;
  SMBIOS_TABLE_ENTRY_POINT *Eps;
  SMBIOS_STRUCTURE         *Header;
  UINT8                    *Ptr;
  UINT8                    *End;
  UINTN                    FormattedLength;
  UINTN                    StructureCount;

  if (SystemTable == NULL) {
    return EFI_INVALID_PARAMETER;
  }

  Eps = NULL;

  //
  // 1. Locate the SMBIOS 2.x entry point in the UEFI
  //    System Configuration Table.
  //
  for (Index = 0;
       Index < SystemTable->NumberOfTableEntries;
       Index++) {

    if (CompareGuid (
          &gEfiSmbiosTableGuid,
          &SystemTable->ConfigurationTable[Index].VendorGuid
          )) {

      Eps = (SMBIOS_TABLE_ENTRY_POINT *)
              SystemTable->ConfigurationTable[Index].VendorTable;
      break;
    }
  }

  if (Eps == NULL) {
    Print (L"SMBIOS 2.x entry point not found.\n");
    return EFI_NOT_FOUND;
  }

  //
  // 2. Validate the SMBIOS 2.x anchor.
  //
  if (CompareMem (
        Eps->AnchorString,
        "_SM_",
        4
        ) != 0) {

    Print (L"Invalid SMBIOS 2.x anchor.\n");
    return EFI_COMPROMISED_DATA;
  }

  //
  // 3. Validate the intermediate anchor.
  //
  if (CompareMem (
        Eps->IntermediateAnchorString,
        "_DMI_",
        5
        ) != 0) {

    Print (L"Invalid SMBIOS intermediate anchor.\n");
    return EFI_COMPROMISED_DATA;
  }

  //
  // A production implementation should also validate:
  // - EPS Length and primary checksum
  // - Intermediate checksum
  // - Table address and table length
  //
  Print (
    L"SMBIOS Version: %d.%d\n",
    Eps->MajorVersion,
    Eps->MinorVersion
    );

  Print (
    L"Table Address: 0x%08x\n",
    Eps->TableAddress
    );

  Print (
    L"Table Length: 0x%04x\n",
    Eps->TableLength
    );

  Print (
    L"Structure Count: %d\n",
    Eps->NumberOfSmbiosStructures
    );

  //
  // 4. Set the table boundaries.
  //
  Ptr = (UINT8 *)(UINTN)Eps->TableAddress;
  End = Ptr + Eps->TableLength;

  StructureCount = 0;

  //
  // 5. Traverse structures within the table boundary.
  //
  while (Ptr < End) {

    //
    // A complete SMBIOS structure needs at least
    // the 4-byte common header.
    //
    if ((UINTN)(End - Ptr) < sizeof (SMBIOS_STRUCTURE)) {
      Print (L"Truncated SMBIOS structure header.\n");
      return EFI_COMPROMISED_DATA;
    }

    Header = (SMBIOS_STRUCTURE *)Ptr;
    FormattedLength = Header->Length;

    if (FormattedLength < sizeof (SMBIOS_STRUCTURE) ||
        FormattedLength > (UINTN)(End - Ptr)) {

      Print (L"Invalid formatted structure length.\n");
      return EFI_COMPROMISED_DATA;
    }

    Print (
      L"Type=%d, Length=%d, Handle=0x%04x\n",
      Header->Type,
      Header->Length,
      Header->Handle
      );

    //
    // Move to the end of the formatted section.
    //
    Ptr += FormattedLength;

    //
    // Find the double-null string-set terminator.
    // Keep every read inside the table boundary.
    //
    while ((UINTN)(End - Ptr) >= 2) {

      if (Ptr[0] == 0 && Ptr[1] == 0) {
        break;
      }

      Ptr++;
    }

    if ((UINTN)(End - Ptr) < 2) {
      Print (L"Missing SMBIOS structure terminator.\n");
      return EFI_COMPROMISED_DATA;
    }

    //
    // Skip the two null bytes.
    //
    Ptr += 2;
    StructureCount++;

    //
    // Type 127 marks the end of the SMBIOS table.
    //
    if (Header->Type == 127) {
      break;
    }

    //
    // Do not traverse beyond the count reported
    // by the SMBIOS 2.x entry point.
    //
    if (StructureCount >= Eps->NumberOfSmbiosStructures) {
      break;
    }
  }

  Print (
    L"Structures traversed: %d\n",
    StructureCount
    );

  return EFI_SUCCESS;
}

7.2 Important Notes About the Example

#

The example demonstrates the basic discovery and traversal flow, but several details deserve attention in real firmware projects.

Checksum validation

Checking the _SM_ and _DMI_ anchors does not fully validate the EPS. The primary checksum must cover the number of bytes specified by the EPS Length field, and the intermediate checksum must be checked over its defined region.

Pointer and length validation

The SMBIOS table address is a physical address supplied by firmware. Before dereferencing it, code must ensure that the address and declared table length are valid and accessible in the current execution environment.

SMBIOS 3.x support

The example intentionally handles only the SMBIOS 2.x entry point. A complete implementation should also locate gEfiSmbios3TableGuid, parse the 3.x EPS layout, and use its 64-bit table address and maximum table size.

Structure parsing

The common header is shared by all structures, but fields after the header depend on the type and SMBIOS version. A parser must check the formatted length before reading type-specific fields.

String handling

String indices are one-based. A value of zero means no string. A robust implementation should validate indices and avoid reading beyond the double-null terminator.

7.3 Using the EDK2 SMBIOS Protocol

#

Manual parsing is useful for understanding the binary format, but UEFI applications and drivers often have a higher-level option.

EDK2 provides the SMBIOS protocol through EFI_SMBIOS_PROTOCOL. Its GetNext() method can enumerate SMBIOS records, while the protocol’s string-related functionality can help retrieve associated strings.

A typical workflow is:

1. Locate the SMBIOS protocol with LocateProtocol().
2. Call GetNext() to enumerate structures.
3. Inspect the common header and structure type.
4. Use the returned record data to access formatted fields and strings.
5. Stop when enumeration reports that no further records are available.

Using the protocol avoids duplicating some low-level table-discovery logic and is generally preferable when developing UEFI applications that only need to consume SMBIOS records.

For low-level firmware debugging, however, understanding the EPS and raw structure layout remains valuable.

🛠️ Practical Parser Design and Common Pitfalls

#

A parser that works with one memory dump may still fail on another machine. SMBIOS tables vary by firmware vendor, SMBIOS version, and platform configuration.

The following checks help make an implementation more reliable.

Validate Before Reading

#

Do not assume that a candidate entry point or structure is valid simply because its signature matches.

Check:

• The EPS anchor and declared length.
• The EPS checksum and intermediate checksum for SMBIOS 2.x.
• The SMBIOS 3.x entry-point checksum when applicable.
• The structure header length.
• The table boundary before every memory read.
• The double-null string-set terminator.

Do Not Assume Fixed Structure Lengths

#

A Type 0 or Type 1 structure can have different formatted lengths across SMBIOS revisions. Newer versions may append fields.

Use the structure’s own Length field and verify that each field you intend to read is present.

Handle Missing and Invalid Strings

#

A string index of zero means that the field has no associated string. Firmware may also publish an index that does not correspond to an available string.

Do not assume that every vendor, product, or serial-number field contains a valid string.

Treat SMBIOS Values as Firmware-Provided Metadata

#

Serial numbers, UUIDs, product names, and memory details are populated by firmware. They can be absent, duplicated, incorrectly formatted, or changed by OEM customization.

SMBIOS is useful for inventory and diagnostics, but it should not be used as a security boundary or as the sole source of device identity.

Support Both Entry-Point Versions

#

A parser designed only for SMBIOS 2.x may fail to handle systems that expose SMBIOS 3.x. Check both UEFI configuration-table GUIDs and select the appropriate entry-point parser.

🔧 From Entry Point to Hardware Inventory

#

The complete SMBIOS access process can be summarized in three stages:

1. Locate the entry point. In legacy BIOS environments, scan the conventional memory region for the appropriate signature and validate the entry point. In UEFI, search the System Configuration Table for the SMBIOS 2.x or 3.x GUID.
2. Read the table metadata. Obtain the table address and its size or maximum size from the relevant entry-point structure.
3. Traverse and decode structures. Walk each record using its formatted length and double-null string terminator, then interpret fields according to the structure type and SMBIOS version.

The key concept is that the entry point is an index to the data table, not the data itself. The actual hardware and firmware information is stored in the sequence of SMBIOS structures.

Whether the goal is to inspect a BIOS version, identify a motherboard, inventory installed memory, or build a firmware diagnostic utility, understanding this layout provides a foundation for working with system information at the BIOS and UEFI level.

For more, please read another two artciles below:

• UEFI BIOS Explained: Architecture, Boot Flow, and Secure Boot
• Essential Linux Commands for Developers and Sysadmins — includes dmidecode for inspecting SMBIOS information.