I2C, SMBus, PMBus and I3C Explained: BMC Sideband and Firmware Security

I2C, SMBus, PMBus and I3C are the slow, low pin count buses that connect sensors, memory module EEPROMs, power regulators, batteries and management controllers on a circuit board. None of them authenticates who is talking. Protect them with board design, host and BMC access control, write protection, and device attestation using SPDM over MCTP.

This guide sits next to our battery management system firmware guide (SMBus fuel gauges), our OpenBMC explainer, our SPDM post and our SPI flash write protection guide. Here we stay on the wires between those parts: what each bus is, how a BMC uses them for sideband management, and what the standards say about protecting them.

Every version, date and quoted requirement below comes from the specifications and official documentation, fetched on 25 October 2026. Everything here is defensive: mechanisms and design controls, not ways to read or write other people's hardware.

Key takeaways

• I2C came from Philips Semiconductors (now NXP) in 1982: two wires (SDA and SCL), 7 or 10 bit addresses, and speeds from 100 kbit/s to 3.4 Mbit/s. The current specification is UM10204 revision 7.0 of 1 October 2021.
• SMBus (1.0 on 15 February 1995, current 3.3.1 of 20 October 2024) is a stricter profile of I2C that adds a 25 to 35 ms clock low timeout, an optional CRC-8 Packet Error Code, address resolution and alerts.
• PMBus is an open command language for power supplies and voltage regulators that runs over SMBus. Its own WRITE_PROTECT command is "not intended to provide protection against deliberate or malicious changes," in the words of the specification.
• MIPI I3C (v1.0 in 2016, v1.2 in February 2025) is the successor to I2C. It assigns addresses dynamically, lets targets raise in-band interrupts on the data line, runs at a typical 12.5 MHz with faster HDR modes, and can share a bus with suitable legacy I2C devices. DDR5 memory modules use an SPD hub that can speak I3C.
• BMCs use these buses for sideband management, with DMTF's MCTP carrying PLDM, NC-SI and SPDM over SMBus/I2C and I3C.
• No bus level authentication exists. The MCTP base specification says plainly that MCTP "will not define any additional security mechanisms" and leaves security to the protocols it carries. Defence therefore comes from bus segmentation, access control on the host and BMC, write protection on critical devices, firmware resiliency under NIST SP 800-193, and SPDM attestation.
• On Linux, list adapters with i2cdetect -l, restrict /dev/i2c-*, read through kernel drivers, and inventory regulator, CPLD and BMC firmware.

Timeline: how the board level buses evolved

The dates below come from the revision history tables inside each specification, or from the publishing body's own pages.

What is I2C?

Origins and the current specification

The I2C bus specification and user manual, NXP document UM10204, describes the bus in its abstract: Philips Semiconductors, now NXP Semiconductors, "developed a simple bidirectional 2-wire bus for efficient inter-IC control." The name is short for Inter-IC. Its revision table lists the original release in 1982, version 1.0 in 1992, version 2.0 in 1998, version 2.1 in 2000, and then revisions 3 (2007), 4 and 5 (2012), 6 (April 2014) and 7 (1 October 2021).

Revision 7 changed vocabulary rather than electrical behaviour: it replaced "master" and "slave" with "controller" and "target" throughout, to align with the MIPI I3C specification. We use the new terms in this post. The Linux kernel's own introduction calls I2C "a protocol developed by Philips" and points readers to UM10204 version 7 as "the latest official I2C specification."

The usual NXP link for UM10204 returned a 404 on 25 October 2026, so we read revision 7 from an archived copy; search NXP's documentation portal for "UM10204" for the current file.

Two wires and open drain signalling

I2C uses two lines: SDA for data and SCL for clock. Both are open drain or open collector, pulled up to the supply by resistors. Any device can pull a line low; nobody drives it high. That is what lets many devices share two wires without fighting each other, and it is also why a single stuck device can hold the whole bus low.

A transfer starts with a START condition, followed by a 7 bit target address and a read or write bit. The addressed target acknowledges by pulling SDA low for one clock, and data then moves in 8 bit bytes, each acknowledged. A STOP condition ends the transfer. A target that needs more time can hold SCL low, which the specification calls clock stretching.

Addresses

Seven bit addressing gives 128 addresses, but several are reserved. The SMBus specification reproduces the I2C reservations in its Appendix C: address 0000 000 with a write bit is the General Call address, the same address with a read bit is the START byte, 0000 001 is the CBUS address, 0000 010 is reserved for a different bus format, and 0000 1XX introduces High-speed mode controller codes. Ten bit addressing uses the pattern 1111 0XX followed by a second byte. UM10204 notes that devices with 7 bit and 10 bit addresses can share a bus, and that 10 bit addressing "is not being widely used."

Addresses are set by the chip design, often with a few pins strapped high or low on the board. Two identical sensors therefore need different strap settings, a multiplexer, or separate buses. There is no discovery, no identity and no authentication: a target is whatever answers at that address.

Speed modes

UM10204's abstract lists the modes:

Fast-mode Plus arrived in revision 3 (2007). Server management buses commonly run in the 100 kHz and 400 kHz classes.

How does SMBus differ from I2C?

Who owns SMBus and what version is current

The System Management Bus specification is published by the System Management Interface Forum (SMIF) at smbus.org. Its revision table lists version 1.0 on 15 February 1995, 1.1 on 11 December 1998, 2.0 on 3 August 2000, 3.0 on 20 December 2014, 3.1 on 19 March 2018, 3.2 on 12 January 2022, 3.3 on 12 May 2024 and 3.3.1 on 20 October 2024, which smbus.org lists as the current release.

SMBus started life in the smart battery world: version 1.0 "defines a 2-wire interface through which the battery can communicate with the charger, a system host or other power-related components," according to the forum's description. It then became the standard management bus on PC and server mainboards. The Linux kernel documentation puts it simply: "Modern PC mainboards rely on SMBus."

What SMBus adds on top of I2C

SMBus is mostly a subset of I2C signalling with stricter rules. The kernel documentation describes it as "mostly a subset of I2C protocols and signaling," and notes that "some SMBus protocols add semantics beyond what is required to achieve I2C branding." The differences that matter most:

Timeouts. I2C lets a target stretch the clock forever. SMBus does not. Table 2 of SMBus 3.3.1 sets tTIMEOUT, the clock low timeout, at a minimum of 25 ms and a maximum of 35 ms in every speed class. A device that sees the clock held low for longer than the minimum must reset its interface by the maximum. A cumulative clock low extension limit of 25 ms applies to targets. This turns a stuck device into a recoverable fault rather than a hung bus.

Packet Error Checking (PEC). SMBus defines an optional Packet Error Code appended to each transaction. The specification describes it as an 8 bit cyclic redundancy check using the polynomial x^8 + x^2 + x + 1, calculated over the whole transaction. PEC catches electrical noise and dropped bits. It is not a security control: anyone who can drive the bus can compute a valid CRC.

Address Resolution Protocol (ARP). SMBus can assign addresses dynamically to devices that support it, using a unique device identifier. This solves address collisions on large boards. It does not authenticate the device that claims an identifier.

SMBALERT# and the Alert Response Address. SMBus adds an optional interrupt line, SMBALERT#. A device that needs attention pulls it low, and the host reads the Alert Response Address (0001 100 with the read bit) to learn which device it was. Version 3.3 made writing to that address explicitly invalid.

Host Notify. A device can become a controller for one transaction and write its own address plus two data bytes to the SMBus Host address (0001 000). The specification frames this as a way to "prevent messages coming to a SMBus Host from unknown devices in unknown formats." It identifies the sender by address only.

Speed classes and protocols. SMBus 3.x defines 100 kHz, 400 kHz and 1 MHz classes and a fixed set of transaction shapes, from Quick Command and Read Byte to Block Read, Write 64 and the ZONE READ and ZONE WRITE protocols used by PMBus.

Where SMBus appears in PCs and servers

• Memory module SPD. Each DIMM carries a Serial Presence Detect device that tells firmware the module's size, timings and manufacturer. The i2c-tools decode-dimms manual says it reads "memory module SPD EEPROMs" through the kernel's eeprom, at24 or ee1004 (DDR4) drivers. On DDR5, the SPD device is the SPD5118 hub, covered below.
• Smart batteries and chargers. SMBus reserves addresses for the Smart Battery (0001 011), the Smart Battery Charger (0001 001) and the Smart Battery Selector or System Manager (0001 010).
• Sensors, regulators and FRU EEPROMs. Temperature and fan monitors, PMBus power devices, and the small EEPROMs that hold board part and serial numbers.
• Add in cards. Network adapters, storage controllers and accelerators often expose a management endpoint on SMBus, increasingly using MCTP.

What is PMBus?

The standard and its parts

PMBus describes itself as "an open standard digital power-management protocol." The PMBus site says about 40 member companies "adopt, promote, and improve the standard," and that the PMBus and AVSBus names are trademarks of SMIF, Inc., the same forum that publishes SMBus. The archive lists revision 1.0 from March 2005 through 1.3.1 from March 2015, and says the current specification is revision 1.4, and that revisions 1.3 through 1.4.1 consisted of three parts: General Requirements, Transport and Electrical Interface; the Command Language; and the Adaptive Voltage Scaling Bus (AVSBus), which has since been replaced by a separate AVSBus specification.

Part II, the command language, is what makes PMBus useful: shared one byte command codes, so a BMC can manage regulators from different manufacturers the same way.

The command language in practice

We read revision 1.3.1 Part II, the most recent revision freely available in the archive. Commands fall into groups:

• On, off and margining. OPERATION turns an output on or off and selects margin high or margin low. ON_OFF_CONFIG decides whether the device obeys OPERATION, a control pin, or both.
• Output voltage. VOUT_COMMAND sets the output voltage, with related commands for margins, trim and transition rates.
• Telemetry. READ_VIN, READ_VOUT, READ_IOUT, READ_POUT, READ_TEMPERATURE and similar commands return live measurements. STATUS_WORD and the STATUS_* family report faults.
• Identity. MFR_ID, MFR_MODEL, MFR_REVISION, MFR_LOCATION, MFR_DATE and MFR_SERIAL hold manufacturer data. PMBUS_REVISION (command code 98h) reports which revision of PMBus the device implements.
• Persistence. STORE_DEFAULT_ALL copies the device's operating memory into non-volatile memory, and RESTORE_DEFAULT_ALL copies it back. The specification warns that using STORE_DEFAULT_ALL while the device delivers power can have "unpredictable, undesirable or even catastrophic results."

Why power telemetry and power commands matter for security

The single most useful sentence for security teams in the PMBus command language is in section 11.1. The WRITE_PROTECT command "is used to control writing to the PMBus device. The intent of this command is to provide protection against accidental changes. This command is not intended to provide protection against deliberate or malicious changes." WRITE_PROTECT can block all writes except to itself, or allow only OPERATION and PAGE, or also ON_OFF_CONFIG and VOUT_COMMAND. Anyone who can write to the device can also clear it.

That matters because the regulators on a server board feed the processors, memory and accelerators. A component that can issue PMBus writes can change output voltage within the device's limits, change fault responses, or turn rails off. By mistake or on purpose, that is an availability problem and potentially an integrity one. Telemetry has a quieter risk: fine grained power readings can reflect what the system is doing, so access to them deserves a decision rather than a default. The defensive conclusion is the same in both cases: only the BMC, or a narrowly scoped host driver, should be able to reach regulators, and regulator configuration counts as what NIST SP 800-193 calls critical data.

NIST SP 800-193 says that critical data "shall be modifiable only through the device itself or defined interfaces provided by device firmware," and that unauthorised changes to critical data "could modify or disable important security-relevant functions provided by the platform, or prevent the device from functioning at all." Regulator configuration fits that description.

The Linux PMBus driver documentation adds a practical note. The driver "does not probe for PMBus devices, since there is no register which can be safely used to identify the chip," and there is "no well defined address range for PMBus devices." Devices have to be declared explicitly in firmware tables or device tree.

What is MIPI I3C?

Versions and status

MIPI Alliance describes I3C as "a medium-speed, utility and control bus interface for connecting peripherals to an application processor," and as "the successor to I2C, incorporating the key capabilities of legacy I2C and SPI interfaces." Its specification page lists MIPI I3C v1.0 (2016), v1.1 (2019), v1.1.1 (June 2021) and v1.2 (February 2025) as member versions. MIPI I3C Basic, a subset with a public version anyone can download, appeared as v1.0 in 2018, v1.1.1 in 2021 and v1.2 in April 2025.

What I3C changes

Dynamic addressing. The Linux I3C protocol documentation explains that "each device on the I3C bus has to be assigned a dynamic address to be able to communicate." Discovery and assignment happen in one procedure, Dynamic Address Assignment (DAA), during which each device reports a Bus Characteristic Register (BCR), a Device Characteristic Register (DCR) and an identifier. The kernel documentation calls I3C "closer to a discoverable bus like USB than it is to I2C or SPI." Devices that also have a static legacy I2C address can answer I2C transfers before DAA.

In-band interrupts (IBI). A target can request attention by pulling SDA at the start of a frame, without a separate interrupt wire. The dynamic address doubles as priority: in the kernel's words, "the lower the dynamic address the higher the priority." Controllers can disable interrupts for one device or all of them.

Hot-Join. A device that powers up late, or sits on a plug in card, can announce itself and ask for an address. The controller may assign one or ignore the request.

Speed. Single data rate (SDR) transfers run at a typical clock of 12.5 MHz, per the kernel documentation. The specification also defines High Data Rate (HDR) modes. The kernel lists three: HDR-DDR (double data rate), HDR-TSP (ternary symbol pure, only on buses with no I2C devices) and HDR-TSL (ternary symbol legacy, usable with I2C devices present). Check the MIPI specification for the current set.

Legacy compatibility. MIPI says I3C and I2C devices "can coexist on the same bus." The OCP DC-SCM specification spells out the condition: legacy devices on an I3C bus must be I2C "responder-only" devices that support Fast-mode "with a true 50ns glitch filter on SCL, and no responder clock stretching."

Multiple controllers. I3C supports a primary controller and secondary controllers that can request bus ownership. DC-SCM notes that "I3C supports multiple initiators on the same bus, but optional muxes can be added to eliminate secondary initiator negotiation." From a security view, fewer possible controllers on a bus means fewer components that can issue commands.

DDR5 SPD hubs and sideband buses

JEDEC's JESD300-5B.01, published in May 2023, is titled the "SPD5118 Hub and Serial Presence Detect Device Standard." Its public abstract says it "defines the specifications of interface parameters, signaling protocols, and features for DDR5 Serial Presence Detect EEPROM with Hub function."

The Linux spd5118 hardware monitoring driver supports "SPD5118 (JEDEC JESD300) compliant temperature sensors, which are used on many DDR5 memory modules." It notes that "some systems use the sensor to prevent memory overheating by automatically throttling the memory controller," scans I2C addresses 0x50 to 0x57, and exposes the SPD data through an eeprom attribute.

OCP's DC-SCM 1.0 specification, which moves the BMC and root of trust onto a removable Datacenter Secure Control Module, provides four I3C buses on the module connector, "intended to enable future uses of I3C for HPM features such as DDR5 SPD," where HPM is the Host Processor Module, the motherboard. Its electrical section requires I2C interfaces to follow SMBus 3.0 and I3C interfaces to follow MIPI I3C v1.1.

How the four buses compare

How does a BMC use these buses for sideband management?

Sideband versus in band

A baseboard management controller is a separate computer on the motherboard. CISA's June 2023 alert describes BMCs as "trusted components designed into a computer's hardware that operate separately from the operating system (OS) and firmware." To report temperatures, power, inventory and add in card health whether or not the host is running, the BMC reaches devices over sideband buses: I2C, SMBus, PMBus and I3C segments wired from the BMC, with traffic that never passes through the host processor.

Our rack server build guide shows where these traces sit.

MCTP: a message layer for management

Raw SMBus reads and writes are fine for a temperature sensor. A network card or GPU needs something richer. DMTF's Management Component Transport Protocol (MCTP), DSP0236, provides it: a small packet protocol with 8 bit endpoint IDs (EIDs), message types, fragmentation, bridging between different physical buses, and a bus owner that hands out EIDs. Version 1.3.3, dated 25 March 2024, is the current published base specification.

MCTP runs over several physical "bindings":

• SMBus/I2C, DSP0237, version 1.2.0 of 6 April 2020. Version 1.1.0 (16 February 2017) added a 1 MHz speed mode.
• I3C, DSP0233, version 1.0.1 of 25 March 2024 (1.0.0 was released on 24 June 2021). In the I3C binding a target with a message to send raises an in-band interrupt with the mandatory data byte 0xAE, and the controller then reads the packet.
• PCIe vendor defined messages and other bindings, which we do not cover here.

Linux supports MCTP natively. The kernel networking documentation describes "a socket-based interface to send and receive MCTP messages, through an AF_MCTP, SOCK_DGRAM socket," with physical bindings as drivers under drivers/net/mctp/ and each binding instance modelled as a network interface. OpenBMC uses this stack on the BMC side.

The MCTP base specification is explicit about security in section 8.13: "The basic premise of MCTP is that higher layer protocols will fulfill security requirements (for example, confidentiality and authentication) for communication of management data... The MCTP protocol itself will not define any additional security mechanisms." Section 8.14 adds that MCTP "has been optimized for communications that occur within a single computer system platform." In other words, MCTP trusts the board.

What MCTP carries: PLDM, NC-SI and SPDM

PLDM. DMTF's Platform Level Data Model, DSP0240 (base specification 1.2.0, 20 June 2024), is "a layered transactional protocol" that lets a requester, usually the management controller, discover which PLDM message types and commands an endpoint supports. Separate PLDM specifications cover monitoring, inventory and firmware update.

PLDM for Firmware Update, DSP0267 version 1.3.0 of 13 December 2023, defines how an update agent, normally the BMC, pushes firmware to a device such as a network card. Its section 7.9 says signing the whole update package is "not within the scope of this specification," and that firmware components "are required to be authenticated by the FD or downstream device through methods defined by the FD or downstream device manufacturer." Whether a card checks signatures on firmware pushed over the management bus depends on the card, so ask the vendor.

NC-SI. The Network Controller Sideband Interface, DSP0222 version 1.2.0 of 25 August 2023, lets a BMC share the host's network adapter for management traffic. It defines a 3.3 V RMII-Based Transport (RBT) with its own electrical rules, and NC-SI commands can also travel over MCTP. A shared NIC puts management and host traffic on the same physical port, so isolation depends on VLANs and switch configuration; a dedicated management port makes the segmentation CISA and NSA recommend easier to prove.

SPDM. The Security Protocol and Data Model, DSP0274 (version 1.3.0 of 28 June 2023 in our fetch), is the protocol that finally adds identity. Its requester and responder messages let a BMC or host collect a device's certificate chain (GET_DIGESTS and GET_CERTIFICATE), prove the device holds the matching private key (CHALLENGE), read signed firmware measurements (GET_MEASUREMENTS), and set up an encrypted and authenticated session (KEY_EXCHANGE), with optional mutual authentication. SPDM is transport independent; DSP0274 points to DSP0275, the SPDM over MCTP binding, for running it over the buses in this post. Our SPDM explainer covers the flows in detail.

DC-SCM: putting the BMC and root of trust on a card

The OCP DC-SCM 1.0 specification moves the BMC, its flash and a platform root of trust onto a removable module, connected to the host board by a defined connector that carries I2C, I3C, PCIe, NC-SI and other signals. Its interoperability section expects that matching a module to a board may require "different firmware sets (BMC firmware, DC-SCM CPLD and HPM FPGA firmware)" to account for differences such as "I2C mapping" and fan control. Each of those is firmware to track. Silicon roots of trust such as Caliptra sit on the same path and are often what makes SPDM responses trustworthy.

What can a compromised host or BMC reach on these buses?

We describe this conceptually, to help with threat modelling and design reviews. The answer depends entirely on the board's wiring, which is why the first step in any review is a bus map.

A compromised BMC typically controls every sideband segment it is wired to: sensors, fans, regulators, FRU EEPROMs, SPD hubs and MCTP endpoints on add in cards. That is why CISA and NSA treat the BMC as high value and ask owners to harden credentials, keep firmware current and segment the management network.

A compromised host with kernel privileges can reach whatever SMBus or I2C controllers the platform exposes to it, often including memory SPD and some sensors. Whether it can reach regulators or BMC segments depends on the board: some designs isolate host and BMC buses fully, others share segments through multiplexers either side can switch.

A faulty or untrusted device on a shared segment can hold the bus low or answer at another device's address. Timeouts allow recovery, but nothing at the bus layer proves which device is speaking.

The design conclusions: map which components can act as a controller on each segment, give sensitive devices the smallest set of controllers (ideally only the BMC or root of trust), and use SPDM over MCTP for anything you need to trust.

Security properties and design guidance

SPD write protection

Memory module SPD contents tell firmware how to train and run memory, so altered SPD data can stop a system booting or run memory outside its rated timings. The DDR5 details sit in JESD300-5B.01, which needs a JEDEC account, and we could not read the full text. For a review, ask the module and board vendors in writing whether SPD contents are write protected on the modules you buy and whether platform firmware blocks host writes to SPD, rather than testing it on production hardware.

Linux i2c-dev access

Once the i2c-dev module is loaded, the kernel documentation says it is "possible to access all devices on an adapter from userspace," through character devices named i2c-0, i2c-1 and so on. These are usually root owned, sometimes with an i2c group. Granting that group to a service account gives it raw access to every device on the adapter, so treat it like membership of a disk group.

Device attestation with SPDM over MCTP

SPDM is the standards based answer to "which device is this, and is it running the firmware I expect?" A BMC or host acting as an SPDM requester validates the device's certificate chain to a trusted root, sends a challenge with a fresh nonce, and reads signed measurements of the device's firmware and configuration. Over SMBus/I2C or I3C, SPDM messages ride inside MCTP using DSP0275. Once a session is established, later management traffic can be protected by SPDM secured messages, closing the gap that MCTP leaves open. It also needs a record of expected measurements per firmware version, which is an inventory problem as much as a cryptography one.

Platform firmware resiliency: NIST SP 800-193

NIST SP 800-193 (May 2018) organises firmware security around protection, detection and recovery of firmware code and critical data. It names the BMC among platform components whose firmware must be protected, and its rules on critical data and authenticated updates map directly onto regulator configuration, SPD contents and add in card firmware reached over these buses.

Step by step on Linux: read only inventory of board level buses

The steps below are read only. Do not scan unknown buses, run write commands or instantiate devices at guessed addresses on production hardware. The i2cdetect manual page warns: "This program can confuse your I2C bus, cause data loss and worse!"

Step 1: list the I2C and SMBus adapters, without probing

# Is the userspace interface loaded at all?
lsmod | grep -E '^i2c_dev' || echo "i2c-dev not loaded"

# List adapters the kernel registered (this does NOT touch the bus)
i2cdetect -l

# The same information from sysfs, no tools required
for a in /sys/class/i2c-adapter/i2c-*; do
  printf '%s\t%s\n' "$(basename "$a")" "$(cat "$a/name")"
done

i2cdetect -l reads the kernel's adapter list without sending traffic. Adapter numbers can change between boots, so scripts should match on the adapter name.

Step 2: see which devices the kernel already bound

# Devices instantiated by firmware tables, device tree or drivers
ls /sys/bus/i2c/devices/

# Name and driver for each one
for d in /sys/bus/i2c/devices/*-*; do
  drv=$(basename "$(readlink -f "$d/driver" 2>/dev/null)" 2>/dev/null)
  printf '%s\t%s\t%s\n' "$(basename "$d")" "$(cat "$d/name" 2>/dev/null)" "${drv:-unbound}"
done

# I3C buses and devices, if the platform has any
ls /sys/bus/i3c/devices/ 2>/dev/null

Entries look like 0-0050, meaning adapter 0, address 0x50. This tells you what is on each bus without sending a single probe.

Step 3: check who can open /dev/i2c-*

ls -l /dev/i2c-* 2>/dev/null
getfacl /dev/i2c-* 2>/dev/null | grep -v '^#'

# Which udev rules touch i2c devices, and which groups they grant
grep -rnE 'i2c' /etc/udev/rules.d /usr/lib/udev/rules.d /lib/udev/rules.d 2>/dev/null

# Who is in an i2c group, if one exists
getent group i2c

You want crw------- or crw-rw---- with a group that contains no service accounts.

Step 4: read sensors through the kernel's hwmon drivers

# Every hardware monitor the kernel registered, with its chip name
for h in /sys/class/hwmon/hwmon*; do
  printf '%s\t%s\n' "$(basename "$h")" "$(cat "$h/name")"
done

# Readable labels and values for one monitor (replace hwmon3)
grep -H . /sys/class/hwmon/hwmon3/*_label /sys/class/hwmon/hwmon3/*_input 2>/dev/null

PMBus regulators bound to the pmbus driver, or to a chip specific PMBus driver, show voltage, current, power and temperature readings here.

Step 5: read memory SPD data through the kernel drivers

# DDR5: spd5118 driver exposes temperature and the SPD contents
ls /sys/bus/i2c/drivers/spd5118/ 2>/dev/null
# DDR4: ee1004 driver
ls /sys/bus/i2c/drivers/ee1004/ 2>/dev/null

# Decode what is already exposed (read only)
decode-dimms 2>/dev/null | head -60

The kernel's spd5118 documentation says SPD data "is available from the 'eeprom' binary attribute file attached to the chip's I2C device." decode-dimms reads through the eeprom, at24 or ee1004 drivers. Neither needs raw bus access. Record module part numbers and serial numbers in your hardware inventory.

Step 6: inventory BMC firmware over Redfish (read only)

On the management network, a read only Redfish query lists the firmware the BMC knows about. Use an account with the read only role.

BMC=bmc01.mgmt.example.internal
curl -s --cacert /etc/pki/bmc-ca.pem -u "readonly:$(cat ~/.bmc-ro)" \
  "https://$BMC/redfish/v1/UpdateService/FirmwareInventory?\$expand=.(\$levels=1)" |
  jq -r '.Members[] | [.Id, .Name, .Version, (.Updateable|tostring)] | @tsv'

On many platforms this list includes the BMC, BIOS, CPLDs and sometimes power supplies or regulators. Where regulators or CPLDs are missing, ask the vendor how their firmware and configuration versions are reported. Our Redfish guide covers accounts, roles and TLS for these queries, and the IPMI post explains why the older protocol should be turned off.

Step 7: add board level firmware to your SBOM

CycloneDX 1.6 includes firmware and device component types, so you can record board level firmware next to software. A minimal entry for a voltage regulator configuration and a BMC image might look like this:

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "components": [
    {
      "type": "firmware",
      "name": "bmc-image",
      "version": "2.18.0-board-r3",
      "supplier": { "name": "Board vendor" },
      "hashes": [{ "alg": "SHA-256", "content": "<sha256 of the signed image>" }]
    },
    {
      "type": "firmware",
      "name": "vr-cpu0-vcore-config",
      "version": "cfg-0x5A1C",
      "description": "PMBus regulator configuration, read via vendor tool on management network",
      "properties": [
        { "name": "bus", "value": "PMBus, BMC segment 4" }
      ]
    }
  ]
}

Where firmware is built from source, such as OpenBMC, the build system can produce its own SBOM.

Step 8: tighten access where it is not needed

# On servers that never need userspace bus access, stop i2c-dev loading
echo 'blacklist i2c_dev' | sudo tee /etc/modprobe.d/no-i2c-dev.conf

# Confirm after the next reboot
lsmod | grep -E '^i2c_dev' || echo "i2c-dev not loaded"

Test this on a staging machine first. Some monitoring agents and vendor tools rely on i2c-dev, and removing it will stop them.

Common mistakes

1. Probing buses with write cycles on production hardware. Bus scans touch every address and the i2cdetect manual warns of data loss. List devices from sysfs instead and keep bus work to lab hardware.
2. World readable or group writable i2c-dev nodes. A udev rule added for a desktop or monitoring tool can open every adapter to a broad group. Check and remove what nothing needs.
3. Assuming the host and BMC buses are isolated. Isolation is a property of a board, not of the protocols. Get the bus map from the vendor.
4. Treating PEC or WRITE_PROTECT as security. PEC is a CRC against noise. PMBus WRITE_PROTECT is explicitly for accidental changes. Neither stops a component that can already write to the bus.
5. Regulator, CPLD and FPGA firmware missing from inventories. Teams track BIOS and BMC versions and forget the programmable power and glue logic parts that DC-SCM itself lists as separate firmware sets. Add them, with versions and configuration checksums.
6. Trusting add in card firmware updates by default. PLDM firmware update leaves package signing out of scope and leaves component authentication to the device maker. Confirm with each vendor that their devices verify signatures before you allow updates over the management bus.
7. Running BMCs with default credentials on flat networks. CISA and NSA name credentials, updates and segmentation as the commonly overlooked basics.
8. Relying on device addresses as identity. Addresses are strap settings or dynamic assignments. Use SPDM where devices support it, and record expected certificate chains and measurements.

FAQ

What is the difference between I2C and SMBus?

SMBus is a stricter profile of I2C for system management. It adds a clock low timeout of 25 to 35 ms so a stuck device cannot hang the bus, an optional CRC-8 Packet Error Code, an Address Resolution Protocol for dynamic addresses, the SMBALERT# alert line and Host Notify. Many I2C devices work on SMBus, but not every I2C feature is allowed on SMBus.

Is PMBus the same as SMBus?

No. PMBus is a command language for power devices that uses SMBus as its transport. It standardises command codes such as OPERATION, VOUT_COMMAND, READ_VOUT and WRITE_PROTECT, so that controllers from different manufacturers can be managed the same way. Both specifications are published by the System Management Interface Forum.

Is I3C backward compatible with I2C?

Partly. MIPI says I3C and I2C devices can coexist on the same bus, but legacy devices must meet conditions. The OCP DC-SCM specification summarises them: I2C target only devices with Fast-mode support, a true 50 ns glitch filter on SCL and no clock stretching. An I3C controller can talk to those devices using I2C transfers.

Does I2C have any security or authentication?

No. I2C has no authentication, encryption or access control. A device is identified only by its address. Security comes from board design, from limiting which components can act as controllers, and from higher layer protocols such as SPDM over MCTP.

How does a BMC talk to network cards and GPUs?

Usually over MCTP, running on SMBus/I2C, I3C or PCIe. PLDM over MCTP carries sensor readings, inventory and firmware updates; NC-SI lets the BMC share a network adapter; SPDM over MCTP lets the BMC verify the device's identity and firmware measurements.

Is it safe to run i2cdetect on a server?

Listing adapters with i2cdetect -l is safe because it only reads the kernel's adapter list. Scanning a bus is not something to do on production hardware: the tool's own manual warns it can confuse the bus and cause data loss. Use sysfs and kernel drivers to see devices instead.

What is a DDR5 SPD hub?

It is the SPD5118 device on each DDR5 module, defined in JEDEC JESD300-5. It stores the module's Serial Presence Detect data, includes a temperature sensor that some systems use to throttle memory, and can operate on I2C or I3C. Linux supports it with the spd5118 driver.

Should regulator firmware be in my SBOM?

If you are responsible for the hardware, yes. NIST SP 800-193 treats device firmware and critical data as part of platform firmware resiliency. CycloneDX supports firmware and device component types, so regulator, CPLD and BMC firmware can sit next to the software components in the same document.

Where Safeguard fits

Safeguard's fit here is indirect. It does not scan firmware images, read buses, attest devices or generate hardware bills of materials. It covers the software around the board: the open source dependencies and container images in your OpenBMC builds, Redfish automation and fleet tooling. Safeguard scans repositories, container images and SBOM files (safeguard scan --dir ., --image <name>, --sbom <file>), shows which projects contain a given component and version, applies policies and gates in CI, and can open fix pull requests through autonomous remediation, which ships switched off. Bus design, device firmware and signing still come from the board and device vendors.

Board level security still depends on software supply chain hygiene, because BMC images, their Redfish stacks and the fleet tools that talk to them are built from open source components. When one has a known vulnerability, the questions are the usual ones: which builds contain it, what is the fixed version, and how fast can a tested change ship.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

These demos show Safeguard on ordinary software projects, not on buses or device firmware. The first is a real Safeguard CLI session: after install, safeguard opens the interactive terminal, you ask it to fix the lodash CVE in a repository, and it reads the finding and advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. It ends with /permissions, /model and /scan. The same flow applies to the repository holding your Redfish inventory scripts.

Click through it at your own pace, or open it full screen.

Management networks should stay isolated, and so should the machines that build and manage BMC firmware. The local runner demo shows how to set up the runner on your own machine, approve it with its device code, and then scan from the terminal. A runner on a build host inside the management zone can scan the tooling there without opening that network to the outside.

Click through it at your own pace, or open it full screen.

If your team uses Claude, the third demo shows how to connect Claude to the Safeguard MCP server with OAuth and choose which tools Claude can use. An engineer can then ask about vulnerable dependencies in the projects that hold your BMC tooling, using only the tools you have allowed.

Click through it at your own pace, or open it full screen.

To try it on your own repositories, download Safeguard and follow the CLI documentation.

Quick check

Sources

• NXP, UM10204 I2C-bus specification and user manual, Rev. 7.0, 1 October 2021 (archived copy)
• System Management Interface Forum, SMBus specifications page
• System Management Interface Forum, System Management Bus (SMBus) Specification version 3.3.1, 20 October 2024
• PMBus, home page
• PMBus, specification archives
• PMBus, Power System Management Protocol Specification Part II, Command Language, Revision 1.3.1, 13 March 2015
• MIPI Alliance, MIPI I3C and I3C Basic specification page
• JEDEC, JESD300-5B.01 SPD5118 Hub and Serial Presence Detect Device Standard (archived document page)
• DMTF, DSP0236 MCTP Base Specification 1.3.3, 25 March 2024
• DMTF, DSP0237 MCTP SMBus/I2C Transport Binding Specification 1.2.0, 6 April 2020
• DMTF, DSP0233 MCTP I3C Transport Binding Specification 1.0.1, 25 March 2024
• DMTF, DSP0240 PLDM Base Specification 1.2.0, 20 June 2024
• DMTF, DSP0267 PLDM for Firmware Update Specification 1.3.0, 13 December 2023
• DMTF, DSP0222 Network Controller Sideband Interface (NC-SI) Specification 1.2.0, 25 August 2023
• DMTF, DSP0274 Security Protocol and Data Model (SPDM) Specification 1.3.0, 28 June 2023
• Open Compute Project, DC-SCM Specification revision 1.0
• NIST, SP 800-193 Platform Firmware Resiliency Guidelines (May 2018)
• NIST, SP 800-193 full text (PDF)
• CISA, CISA and NSA Release Joint Guidance on Hardening Baseboard Management Controllers (14 June 2023)
• Linux kernel documentation, Introduction to I2C and SMBus
• Linux kernel documentation, Implementing I2C device drivers in userspace (i2c-dev)
• Linux kernel documentation, The SMBus protocol
• Linux kernel documentation, I3C protocol
• Linux kernel documentation, Kernel driver pmbus
• Linux kernel documentation, Kernel driver spd5118
• Linux kernel documentation, Management Component Transport Protocol (MCTP)
• Debian manual page, i2cdetect(8) from i2c-tools
• Debian manual page, decode-dimms(1) from i2c-tools
• CycloneDX, BOM 1.6 JSON schema (component types)

Last reviewed: 25 October 2026. Bus specifications and DMTF standards are revised regularly; check the linked pages for current versions before you design or audit a board.