Bus Evolution: ISA to PCIe 7.0, NVMe and CXL, and the DMA Security Story

The PC expansion bus went from the 8 bit IBM PC bus of 1981 (later called ISA) through MCA, EISA and local buses to PCI in 1992, then AGP for graphics, then PCI Express from 2003. PCIe has roughly doubled its per lane rate each generation, and PCI-SIG released PCIe 7.0 at 128 GT/s in June 2025. NVMe runs storage over PCIe, and CXL reuses the PCIe physical layer for coherent memory and accelerators.

The security thread runs through all of it. Each of these buses lets a device read and write system memory on its own, which is called direct memory access (DMA). That makes every expansion card, NVMe drive and Thunderbolt dock a party that can touch your memory. The defences, from IOMMUs to PCIe link encryption and device attestation, are the part of this history that matters most today.

Key takeaways

• ISA (1981 and 1984), MCA (1987), EISA (1988) and the VESA local bus were the shared parallel buses of the early PC. PCI 1.0 (1992) replaced them with a faster bus that configured itself.
• AGP (specification July 1996, first chipset 1997) gave graphics its own port. PCIe x16 replaced it from 2004.
• PCIe rates went 2.5, 5, 8, 16, 32, 64 and 128 GT/s from 1.0 to 7.0. PCIe 6.0 switched to PAM4 signalling and FLIT encoding, and 7.0 keeps both.
• GT/s is not GB/s. PCIe 7.0's "512 GB/s" on x16 counts both directions; it is about 256 GB/s each way before overhead.
• NVMe (1.0 in 2011, the restructured 2.0 library on 3 June 2021) replaced AHCI, which had one queue of 32 commands built for spinning disks.
• CXL runs CXL.io, CXL.cache and CXL.mem over PCIe wiring. CXL 4.0 reaches 128 GT/s.
• A bus master is a security boundary. Without an IOMMU, a DMA capable device can read or overwrite any physical memory, and the Thunderclap research (NDSS 2019) showed gaps even with one.
• Newer defences: PCIe IDE encrypts the link, TDISP assigns device interfaces to confidential VMs, and DMTF SPDM proves device identity and firmware.
• Inventory matters. Record each device's IDs, firmware, driver, link speed and IOMMU state. Firmware and drivers belong in your SBOMs.

A dated timeline of PC expansion buses

PCI-SIG's site refused our automated requests, so dates marked with an asterisk come from Wikipedia's summaries rather than the standards body. The PCIe 7.0, NVMe 2.0 and latest NVMe dates come from the standards bodies' own releases.

What were ISA, MCA, EISA and VLB, and why did PCI replace them?

The IBM PC bus that became ISA

The 1981 IBM PC had an 8 bit expansion bus that ran at the processor's 4.77 MHz clock. The 1984 PC/AT added a second edge connector that widened the data path to 16 bits and raised the address lines to 24, running at 6 MHz and later 8 MHz. Clone makers later named the design "Industry Standard Architecture", with Compaq credited for the term.

ISA was a shared parallel bus configured by hand. Jumpers and DIP switches picked each card's I/O port, interrupt line and DMA channel, and two cards on the same interrupt meant a machine that froze. ISA also carried the first PC DMA: a motherboard DMA controller moved data between a card and memory, the AT bus added four 16 bit DMA channels, and cards could become bus masters and drive transfers themselves. The 24 address lines are the origin of the 16 MB ISA DMA limit that operating systems carried special code for long afterwards.

MCA, EISA and the VESA Local Bus

By the late 1980s 32 bit processors had outgrown a 16 bit, 8 MHz bus. IBM's 1987 answer, Micro Channel Architecture, configured cards in software, but IBM kept it proprietary and most of the industry refused it. In 1988 the "Gang of Nine" clone makers proposed EISA, a 32 bit bus that still took ISA cards. It found a home in servers but was too expensive for desktops. Graphics cards hit the wall first, and the VESA Local Bus of the early 1990s attached them closer to the processor's own bus. It was fast and cheap but tied to one generation of processor design.

Why PCI won

Intel began PCI around 1990, the 1.0 specification is dated 22 June 1992, and the standard later passed to the PCI Special Interest Group, which still runs PCIe. Three things made it win:

1. Speed. The desktop form was 32 bits at 33 MHz, 133 MB/s peak. Later 66 MHz and 64 bit variants reached 533 MB/s.
2. Processor independence. PCI sat behind a bridge chip, so it was not tied to one processor's timing the way VLB was.
3. Configuration space. Every PCI function exposes 256 bytes of registers giving its vendor and device IDs, class and the memory and I/O ranges it needs. Firmware or the operating system scans the bus at startup and assigns resources. That is the basis of plug and play.

PCI replaced MCA and EISA in servers first, took real desktop share from late 1994, and by 1996 VLB was nearly gone. PCI also made bus mastering normal: any device can start its own memory reads and writes, which is why the specification requires a latency timer to stop one device hogging the bus. That is the root of the DMA security problem later in this post.

Why did AGP exist and why did it disappear?

Mid 1990s 3D graphics needed to stream textures from system memory, and a 133 MB/s PCI bus shared with disks and network cards could not keep up. Intel designed the Accelerated Graphics Port outside PCI-SIG: specification dated July 1996, first chipset (the 440LX) launched 26 August 1997.

AGP's graphics address remapping table (GART) let the card treat scattered pages of system memory as one contiguous "aperture". It is an early, narrow example of an address translation table between a device and memory, the idea the IOMMU later generalised for every device and turned into a protection mechanism.

PCIe arrived on PC boards in 2004, and an x16 slot gave graphics more bandwidth than AGP 8x on the same general purpose bus as everything else. Vendors bridged PCIe chips back to AGP for a while at extra cost, but by mid 2008 PCIe cards dominated and by 2010 no new chipsets supported AGP.

How has PCIe doubled per generation, and what changed in 6.0?

PCI Express kept PCI's software model (configuration space, bus, device and function numbering, bus mastering) and replaced the physical layer. Each device gets its own point to point link of one or more lanes, each lane a pair of differential signal pairs, one per direction, in widths from x1 to x16. Because the software model stayed, operating systems carried over easily, and so did the DMA story: a PCIe endpoint is a bus master by design.

Each generation roughly doubles the per lane rate. PCI-SIG's president called PCIe 7.0 a continuation of the tradition of "doubling the IO bandwidth every three years".

GT/s versus GB/s

GT/s counts symbols on the wire per lane, not useful bytes. To get bytes, subtract encoding overhead, multiply by lanes, then subtract protocol overhead.

• 8b/10b (PCIe 1.0 and 2.0) sends 10 bits per 8 bits of data, so 20 percent is overhead: 2.5 GT/s gives 250 MB/s per lane per direction.
• 128b/130b (PCIe 3.0 to 5.0) cuts overhead to about 1.5 percent, which is why 3.0 at 8 GT/s nearly doubled 2.0 at 5 GT/s.
• FLIT mode (6.0 and 7.0) moves data in fixed size flow control units with error correction built in; the Wikipedia summary gives 242 useful bytes per 256 byte FLIT.

So PCI-SIG's "up to 512 GB/s bi-directionally" for PCIe 7.0 x16 works out as 128 GT/s times 16 lanes, or 256 GB/s, each way, with both directions added together. Useful throughput per direction is nearer 242 GB/s. For reading from an SSD, one direction is what counts.

What changed in PCIe 6.0: PAM4 and FLIT

Up to 5.0, each symbol carried one bit on two voltage levels (non return to zero, NRZ), so doubling the rate meant doubling the frequency, and at 32 GT/s board losses were already severe. PCIe 6.0 moved to PAM4, pulse amplitude modulation with four levels, so each symbol carries two bits and the rate doubles to 64 GT/s without doubling the frequency. The four levels sit closer together, which raises the error rate, so 6.0 added forward error correction and FLIT based encoding. The specification was announced on 11 January 2022, and the Wikipedia summary says hardware arrived in 2025: a specification date is not a product date.

What does PCIe 7.0 deliver, and when?

PCI-SIG announced the PCIe 7.0 specification to its members in June 2025 (the Business Wire release is dated 11 June). According to PCI-SIG, PCIe 7.0 runs at a raw 128.0 GT/s per lane, delivers up to 512 GB/s bidirectional on x16, uses PAM4 and FLIT based encoding like 6.0, improves power efficiency (no figures given) and stays backward compatible with earlier generations.

The named target markets were AI and machine learning, 800G Ethernet, cloud and quantum computing, which tells you where it lands first: data centre accelerators and very fast network adapters, not desktop graphics. An 800 Gb/s port needs about 100 GB/s each way, more than a PCIe 5.0 x16 slot carries and comfortable for 7.0.

The release also said "pathfinding for the PCIe 8.0 specification is already in progress." Secondary reporting describes 8.0 as a 256 GT/s target for around 2028; we could not confirm that on a PCI-SIG page, so treat it as a plan. PCI-SIG gave no product date for 7.0. The roughly three year gap between the 6.0 specification and 6.0 hardware is a fair guide, with servers first.

What is NVMe, and why did it replace AHCI for SSDs?

Before NVMe, most SSDs spoke SATA through the Advanced Host Controller Interface (AHCI), which was built for spinning disks where mechanical seeks dominated. AHCI has one command queue of 32 commands. That suits a disk doing a few hundred operations per second, not flash serving hundreds of thousands across many internal channels.

NVM Express is a register interface and command set that NVM Express, Inc. says was "designed from the ground up" for high bandwidth, low latency non volatile storage on PCIe.

NVMe 1.0 was published on 1 March 2011. On 3 June 2021, NVM Express announced the "rearchitected" NVMe 2.0 library: a base specification, separate command sets (NVM, Zoned Namespaces, Key Value), separate transports (PCIe, Fibre Channel, RDMA, TCP) and the management interface, plus support for hard disks, all backward compatible. Today's specifications page lists command sets including Computational Programs, NVM, SLM, KV and ZNS, transports for PCIe, RDMA and TCP, NVMe Boot and NVMe-MI. It says the latest set was released on 4 August 2026 and marks the old standalone NVMe over Fabrics document obsolete.

For security, an NVMe drive is a PCIe bus master that DMAs into host buffers, and it runs substantial firmware the host updates through admin commands. Its firmware revision is a security fact worth recording, and the IOMMU matters for internal storage too. Microsoft notes that its inbox NVMe, AHCI and USB XHCI controller drivers support DMA remapping, so those devices can be confined.

How does CXL reuse PCIe, and what do CXL.io, CXL.cache and CXL.mem do?

The CXL Consortium describes Compute Express Link as a cache coherent interconnect for processors, memory expansion and accelerators. Its key choice was to reuse the PCIe physical layer and slots. CXL 1.x and 2.0 ran on PCIe 5.0 signalling and CXL 3.0 moved to the PCIe 6.0 physical layer with PAM4. The consortium says CXL 4.0 doubles the rate from 64 to 128 GT/s, keeps the 256 byte FLIT of CXL 3.x, adds native x2 links and support for up to four retimers, and stays backward compatible with every earlier version. In November 2021 the Gen-Z consortium transferred its specifications and assets to CXL.

The kernel documentation groups devices into three types. Type 1 (CXL.io and CXL.cache) caches host memory with none of its own; the example is a smart NIC writing packets into host memory. Type 2 uses all three protocols, typically an accelerator such as a GPU with its own memory. Type 3 (CXL.io and CXL.mem) is the memory expander that adds volatile or persistent RAM to a server, and CXL 2.0 switching lets that memory be pooled among hosts.

Coherency raises the stakes. With plain PCIe, an IOMMU can confine a device's DMA. With CXL.mem the memory itself lives on the device, so a malicious or buggy expander sees every byte stored there, and CXL.cache devices take part in the coherency protocol. That is why CXL 2.0 added link integrity and encryption, and why device authentication matters more as memory moves off the processor package.

What is DMA, and why is a bus master a security boundary?

Direct memory access lets a device move data to or from memory without the processor copying each word. A NIC writes packets into a ring buffer, an NVMe drive writes blocks into the page cache, a GPU reads textures from RAM. Without DMA, modern I/O speeds would be impossible.

The catch: memory protection the processor's MMU enforces for software does not apply to a device. With no translation in the path, a bus master can read or write any address it can name, including kernel code, page tables and encryption keys in RAM. A DMA capable device is therefore a security boundary just as a process boundary is. Three situations make it practical:

1. External PCIe. Thunderbolt, USB4 and CFexpress tunnel PCIe through a port. Microsoft describes "drive-by DMA attacks" where someone plugs a device into an unattended laptop for a few minutes to read secrets or bypass the lock screen. Microsoft also notes its Kernel DMA Protection does not cover older FireWire, PCMCIA, CardBus or ExpressCard ports.
2. Compromised device firmware. A NIC, storage controller or management controller with modified firmware can issue DMA from inside the case.
3. Early boot. Firmware that enables bus mastering before the IOMMU is set up leaves a window; see our post on CWE-1190, DMA enabled too early.

What does an IOMMU do, and what are its known gaps?

An input output memory management unit translates the addresses devices use into physical addresses, as the MMU does for software. The operating system gives each device or group its own mappings, so a device reaches only the memory its driver mapped. Anything else faults and is logged.

On x86, Intel's IOMMU is VT-d and AMD's is AMD-Vi. Firmware describes them through ACPI tables: DMAR on Intel (DRHD entries for the units, RMRR entries for reserved regions) and IVRS on AMD. The Linux kernel documentation shows boot lines such as "PCI-DMA: Using DMAR IOMMU" and fault lines such as "DMAR: ... PTE Write access is not set" or "AMD-Vi: Event logged [IO_PAGE_FAULT ...]". IOMMUs serve two jobs: confining a device or SR-IOV virtual function handed to a VM, and stopping devices reaching host memory they were not given.

Windows Kernel DMA Protection uses the IOMMU to block external PCIe devices whose drivers do not support DMA remapping until an authorised user signs in or unlocks the screen. It needs UEFI support and the IOMMU enabled in firmware, and Microsoft states it does not protect during boot. On Linux, the Thunderbolt subsystem's iommu_dma_protection attribute reads 1 when the IOMMU confines Thunderbolt devices; otherwise the security levels (none, user, secure, dponly, usbonly, nopcie) decide whether PCIe tunnels are created at all.

The known gaps

The Thunderclap research from the University of Cambridge and SRI International, presented at NDSS in February 2019 after disclosure to vendors from 2016, is the best public study of where IOMMU protection fails:

• It is often off. The researchers found IOMMU protection "turned off by default in many systems."
• Shared pages leak. Operating systems put sensitive data on the same pages they map for device communication.
• Device identity is weak. An attacker can put malicious PCIe internals in a case that identifies as a trusted device.
• Address Translation Services (ATS) let a device present already translated addresses; Intel's Linux 5.0 patches enabled the IOMMU for Thunderbolt and blocked an ATS based bypass.

Windows 10 version 1803 enabled IOMMU protection for Thunderbolt on capable hardware, and Apple fixed the specific issue used in the research in macOS 10.12.4. The authors still say the broader design issues remain, and their most complete advice is to disable Thunderbolt in firmware where unneeded and not to connect devices of unknown origin.

Other gaps: RMRR identity mappings let some firmware features keep direct access; iommu=pt keeps internal devices on one to one mappings, weakening host isolation; devices sharing an IOMMU group can talk peer to peer and can only be isolated together; and everything before the OS configures the IOMMU depends on firmware.

What are PCIe IDE, TDISP and DMTF SPDM?

The IOMMU answers "which memory may this device touch?" It does not answer "is this the device I think it is?" or "can someone on the link read or alter the traffic?"

SPDM: who is this device, and what firmware is it running?

The Security Protocol and Data Model (DMTF DSP0274) is a request and response protocol between a host and a device. DMTF's reference implementation, libspdm, shows what each version added: 1.0 brought capability and algorithm negotiation, certificate retrieval, challenge (proving the device holds the key behind its certificate) and signed firmware measurements; 1.1 added key exchange for encrypted sessions, pre shared keys and key update; 1.2 added certificate signing requests and setting certificates; 1.3 added events and measurement extension logs. libspdm tracks DSP0274 1.0.3 through 1.4.1, with 1.4 features still in progress, and follows PCIe Base revision 6.5 and CXL 3.1 for its bindings. SPDM is the answer to Thunderclap's point that devices can lie about who they are. On PCIe its messages travel through a Data Object Exchange (DOE) mailbox, which the Linux PCI TSM code references.

IDE: protect the link

Integrity and Data Encryption adds authenticated encryption to PCIe and CXL traffic between a root port and a device, so a probe or interposer on the link cannot read or silently change transactions. The Linux PCI TSM documentation describes "Selective IDE" streams allocated per host bridge (256 by default), programmed into the endpoint and its root port and recorded in sysfs.

TDISP: give a device to a confidential VM

Confidential computing keeps a VM's memory encrypted even from the hypervisor, which breaks ordinary device passthrough. TDISP defines how a device interface (a TDI, often an SR-IOV virtual function) is locked into a known configuration, attested and moved into a running state for one trusted VM. The Linux PCI TSM API binds a PCI function as a TDI for a KVM guest and tracks transitions from unlocked to locked to run. SPDM supplies identity and measurements, IDE protects the link, TDISP manages assignment. All three need the processor, root port, device, firmware and OS to cooperate, so expect them on recent servers long before laptops.

Decision table: which DMA defence fits which threat

What should a hardware inventory record about buses and devices?

For every machine, especially servers and developer workstations, record:

• Bus address (domain, bus, device, function) to map findings to slots.
• Vendor, device and subsystem IDs and class code.
• Firmware version of every device with its own firmware: NVMe drives, NICs, GPUs, storage and Thunderbolt controllers, and system firmware.
• Driver name and version.
• Negotiated versus maximum link speed and width, which also catches misseated cards or unexpected risers.
• IOMMU state, each device's IOMMU group, and DMA protection on external ports.
• SR-IOV virtual functions and where they are assigned; CXL devices on servers.
• SPDM capability and certificate chain, where supported.

Firmware and drivers are software components with versions and vulnerability histories. CycloneDX has types for them: device for a physical item such as a chipset, device-driver for software that controls a device, and firmware for low level software on hardware; the specification says a device containing firmware should list that firmware as its own component. See hardware supply chain trust boundaries and hardware root of trust for device makers for the wider picture.

Step by step: audit buses, DMA protection and device firmware

These commands read state only, except where step 7 warns you. Run them on machines you administer.

1. List PCIe devices, IDs and drivers (Linux)

lspci -tv     # tree of root ports, switches and endpoints
lspci -nnk    # numeric [vendor:device] IDs and "Kernel driver in use"

2. Check negotiated link speed and width

DEV=0000:01:00.0   # a bus address from lspci
for a in current_link_speed current_link_width max_link_speed max_link_width; do
  echo "$a: $(cat /sys/bus/pci/devices/$DEV/$a)"
done
sudo lspci -vv -s 01:00.0 | grep -E "LnkCap|LnkSta"

A device at 8 GT/s in a 16 GT/s slot, or x4 where you expected x16, is worth a look for performance and as a sign of an unexpected riser or interposer.

3. Confirm the IOMMU is on (Linux)

sudo dmesg | grep -i -E "DMAR|IOMMU|AMD-Vi"
ls /sys/kernel/iommu_groups/ | wc -l        # 0 means no active IOMMU
for g in /sys/kernel/iommu_groups/*; do echo "Group ${g##*/}: $(ls $g/devices)"; done
cat /proc/cmdline                            # look for iommu=pt or intel_iommu=off

If there are no groups, enable VT-d or AMD-Vi (sometimes labelled IOMMU) in firmware.

4. Check Thunderbolt and USB4 DMA protection (Linux)

cat /sys/bus/thunderbolt/devices/domain*/iommu_dma_protection   # 1 = active
cat /sys/bus/thunderbolt/devices/domain*/security               # none, user, secure, ...

Protection 0 with security none means any Thunderbolt device gets a PCIe tunnel without approval.

5. Check Kernel DMA Protection (Windows)

Open Windows Security, then Device security, then Core isolation details, and check Memory access protection, or run msinfo32 and read Kernel DMA Protection. If it is Off and the Hyper-V line for virtualization enabled in firmware reads No, Microsoft's guidance is to enable Intel Virtualization Technology and VT-d in firmware and reboot. If it stays Off, the hardware does not support it. For one device, Device Manager's Details tab shows DMA Remapping Policy: 2 means the driver supports remapping; 0, 1 or no value means it does not. Export driver versions for inventory:

Get-CimInstance Win32_PnPSignedDriver |
  Where-Object { $_.DeviceClass -in 'NET','SCSIADAPTER','HDC','DISPLAY','SYSTEM' } |
  Select-Object DeviceName, DriverProviderName, DriverVersion, DriverDate |
  Export-Csv -NoTypeInformation drivers.csv

6. Record NVMe and other device firmware versions

sudo nvme list                                   # model and firmware revision
sudo nvme id-ctrl /dev/nvme0 | grep -E "^(mn|fr) "
fwupdmgr get-devices                             # devices the firmware update service knows

These only read. Do not run firmware update or format commands during an inventory pass.

7. Inspect SR-IOV and CXL state (servers)

cat /sys/bus/pci/devices/$DEV/sriov_totalvfs /sys/bus/pci/devices/$DEV/sriov_numvfs
ls /sys/bus/cxl/devices/ 2>/dev/null
cxl list -M 2>/dev/null          # cxl-cli from the ndctl project

Warning: per the kernel documentation, writing a number to sriov_numvfs creates virtual functions and writing 0 removes them, which cuts network or storage for any VM using them. Read only; change it in a maintenance window after checking $DEV is the device you mean and which workloads use it.

8. Put devices, firmware and drivers in an SBOM

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "components": [
    { "type": "device", "bom-ref": "nvme0", "name": "Example NVMe SSD",
      "properties": [ { "name": "pci:address", "value": "0000:01:00.0" } ] },
    { "type": "firmware", "bom-ref": "nvme0-fw", "name": "Example NVMe SSD firmware", "version": "3B2QGXA7" },
    { "type": "device-driver", "bom-ref": "linux-nvme", "name": "nvme", "version": "6.8.0-45-generic" }
  ],
  "dependencies": [ { "ref": "nvme0", "dependsOn": ["nvme0-fw", "linux-nvme"] } ]
}

The property name is a local convention. Vendor supplied SBOMs for firmware and drivers beat hand assembled ones when you can get them.

Where Safeguard fits, honestly

Most of this post is outside Safeguard's scope. Safeguard does not inspect silicon, verify SPDM certificates, configure IOMMUs, scan firmware binaries or generate a hardware bill of materials. What it does is analyse software inventories: if vendors supply SBOMs for firmware and drivers, or you assemble CycloneDX files like the one above, Safeguard can ingest them with safeguard scan --sbom <file>, match components against vulnerability databases and show which products contain a given component and version. It also scans the repositories and container images behind the drivers, agents and tools you build, and the local runner and offline mode keep those checks working on lab and air gapped machines. Firmware fixes still come from the device vendor.

Common mistakes

• Reading GT/s as GB/s. 128 GT/s is per lane, before encoding. Do the arithmetic before sizing a server.
• Assuming a faster slot makes a faster device. The link trains to the slower end; a PCIe 4.0 SSD in a 5.0 slot runs at 16 GT/s.
• Treating a specification date as a product date. PCIe 6.0 was final in January 2022 and hardware came years later.
• Assuming the IOMMU is on. Thunderclap found it off by default on many systems. Check groups and the kernel command line on every build.
• Leaving iommu=pt after troubleshooting. It weakens host isolation.
• Trusting device ID strings. Vendor and device IDs are claims; only SPDM style authentication proves origin.
• Forgetting internal devices. A NIC or storage controller with compromised firmware has the same access as an external dock.
• Not recording firmware versions. When an SSD or NIC advisory lands, you will check machines by hand.
• Ignoring the boot window. OS protections start after the OS loads; firmware covers the rest.

FAQ

What is the difference between PCI and PCIe?

PCI (1992) is a shared parallel bus, typically 32 bits at 33 MHz for 133 MB/s. PCIe (2003) keeps PCI's software model but gives each device dedicated serial lanes, which is how it scales to 128 GT/s per lane.

Is PCIe 7.0 out yet?

The specification was released to PCI-SIG members in June 2025: 128 GT/s per lane, up to 512 GB/s bidirectional on x16. PCI-SIG named AI, 800G Ethernet, cloud and quantum computing as targets, so expect server and network hardware first.

How fast is PCIe 6.0 compared to PCIe 5.0?

Twice as fast per lane: 64 GT/s against 32 GT/s, using PAM4 signalling, forward error correction and FLIT encoding. An x16 link carries roughly 121 GB/s each way after overhead, against about 63 GB/s.

Is PCIe backward compatible?

Yes, including PCIe 7.0 according to PCI-SIG. A link negotiates the highest rate both ends support, so mixing generations runs at the older speed.

Why is NVMe faster than SATA SSDs?

SATA SSDs use AHCI, with one queue of 32 commands designed for hard disks. NVMe runs over PCIe lanes with up to 65,535 queues of up to 65,536 commands, so cores submit work in parallel with less locking and latency.

What is CXL used for?

Connecting processors to memory expanders, accelerators and smart NICs over PCIe slots with cache coherency. The most common use is adding and pooling server memory with Type 3 expanders.

What is a DMA attack?

An attack that uses a device's ability to read and write memory directly, bypassing the operating system. It can come from a device on a Thunderbolt port or from compromised firmware inside the case. An enabled IOMMU with DMA remapping drivers limits what the device can reach.

How do I check if Kernel DMA Protection is on?

On Windows, check Memory access protection under Windows Security, Device security, Core isolation details, or the Kernel DMA Protection line in msinfo32. On Linux, read /sys/bus/thunderbolt/devices/domain0/iommu_dma_protection (1 means active) and confirm /sys/kernel/iommu_groups/ is not empty.

What is SPDM in PCIe?

A DMTF protocol that lets a host check a device's certificate, challenge it to prove it holds the private key, and request signed firmware measurements. Later versions add encrypted sessions, which are used to key IDE link encryption.

Fix it without waiting for upstream

Bus and DMA defences live in silicon and firmware, but the machines they protect still run drivers, management agents, firmware update tools and user space stacks built from open source components. When those components carry known vulnerabilities, the same patch and inventory discipline applies, and it is the part your team can act on today.

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 covers eight categories, including dependencies, licenses, security posture and findings. 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. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

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

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature 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. This fork and patch flow is in early access today, so 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

The local runner demo shows how to set up Safeguard's runner on your own machine, approve it with a device code and run scans from the terminal. That is the flow you would use on a lab server or an isolated build host to scan the SBOM you assembled in step 8, or the repositories holding your drivers and management agents, without sending the work elsewhere.

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

The CLI demo is a real session: the Safeguard CLI reads a lodash finding and its advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with approval and pushes nothing. The same approve each step pattern applies when a vulnerable library turns up inside a device management agent or a tool your team ships alongside hardware.

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

The Claude demo shows how to connect Claude to the Safeguard MCP server with OAuth and choose which tools Claude may use. Once connected, you can ask which of your projects contain a given driver or library version from your inventory, and get the answer from your own Safeguard data.

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

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

Quick check

Sources

• Signal Integrity Journal: PCI-SIG releases PCIe 7.0 specification (reprint of the PCI-SIG release)
• NVM Express: specifications
• NVM Express: announcement of the rearchitected NVMe 2.0 library
• NVM Express: about
• CXL Consortium: about CXL
• CXL Consortium: CXL specification
• CXL Consortium: past CXL specifications
• DMTF: libspdm reference implementation
• Microsoft Learn: Kernel DMA Protection
• Thunderclap: IOMMU protection and DMA from untrustworthy peripherals
• Linux kernel: x86 IOMMU support
• Linux kernel: Thunderbolt and USB4 administration
• Linux kernel: PCI Express I/O virtualization (SR-IOV) howto
• Linux kernel: PCI TSM (IDE and TDI) API
• Linux kernel: Compute Express Link documentation
• Linux kernel: CXL devices and protocols
• CycloneDX 1.6 JSON reference
• Wikipedia: PCI Express
• Wikipedia: Industry Standard Architecture
• Wikipedia: Peripheral Component Interconnect
• Wikipedia: Accelerated Graphics Port
• Wikipedia: NVM Express
• Wikipedia: Compute Express Link

Last reviewed: 23 October 2026.