NTB Application in DMA Concealment and Host Isolation

Technical README produced by the research team. This document explains the use of PCIe Non-Transparent Bridge (NTB) for DMA concealment and host isolation. It is intended for lawful research, testing, and authorized forensic use only.

---

Table of contents

1. Overview
2. Key benefits
3. Components and test environment
4. Architecture summary
5. NTB configuration and ATU mapping procedure
6. Data path and operation
7. Validation and test results
8. Limitations and deployment considerations
9. Legal and ethical disclaimer
10. Appendix & references

---

Overview

This README documents an NTB-based architecture that isolates a host PCIe domain from a DMA device domain while enabling controlled, transparent data transfer between them. The design uses a PCIe switch with NTB capability and address translation units (ATU) to map host-visible BAR windows to device physical memory buffers.

The goal is to achieve device concealment at the host PCIe topology level while preserving bidirectional data exchange for legitimate use cases such as authorized memory forensics, secure data acquisition, or system acceleration.

Key benefits

• Physical PCIe domain isolation. The host root complex cannot enumerate devices in the isolated domain.
• Transparent data access. Host reads/writes to an NTB BAR are forwarded to device memory via ATU mappings.
• No host firmware modification required. Implemented using standard PCIe switch capabilities.
• Cross-platform compatibility. Supports heterogeneous host and device platforms.

Components and test environment

Host (PC1)

• Motherboard: example model (Gigabyte X870 used in tests)
• CPU: example model (AMD 9950X used in tests)
• OS: Windows 10 22H2 (unmodified in test)

DMA device (PC2)

• FPGA-based DMA engine (Xilinx XC7A75T used in tests)
• DMA test suite (PCIEECH-DMA used in tests)

PCIe switch / NTB

• PLX PEX8749 or equivalent NTB-capable PCIe switch

Management controller (PC3)

• Embedded controller with PCIe control interface (custom Raspberry Pi with PCIe I/F used in tests)
• Purpose: program ATU mappings and NTB configuration registers

Architecture summary

1. The PCIe switch is partitioned into two domains: the host domain and the device domain.
2. NTB mode enforces topology isolation so the host cannot enumerate devices on the device domain.
3. ATU mappings translate host BAR address ranges to device physical memory addresses.
4. Doorbell registers and interrupt mechanisms provide cross-domain signaling.

Diagram (ASCII):

  [Host (PC1) Root Complex]
             |
         PCIe Link
             |
   +-----------------------+
   |   PLX Switch (NTB)    |
   |  - Host Domain Ports  |<--Mgmt Controller (PC3) programs ATU via I2C/SPI/PCIe regs
   |  - Device Domain Ports |
   +-----------------------+
             |
        NTB Domain Link
             |
  [Device Domain (FPGA DMA Engine)]

Host accesses NTB BAR -> translated by ATU -> mapped to FPGA buffer.
FPGA DMA issues TLPs -> routed by ATU -> host memory.
Doorbell registers signal completion across NTB.

NTB configuration and ATU mapping procedure

The following steps describe a typical management-side configuration flow. Implementation details vary by switch vendor and firmware. Use vendor documentation and register maps for exact sequences.

1. Initialize management interface

   • Connect to the switch management bus (I2C/SPI/PCIe register access) from the controller.

2. Partition ports into domains

   • Configure the switch to allocate one or more ports as the host domain and the remaining ports as the device domain.
   • Enable NTB mode on the boundary between domains.

3. Configure host-side BAR (NTB endpoint)

   • Define a 64-bit BAR window in the host address space (example: 0xC0000000–0xC00FFFFF for a 1 MB window).
   • Program the switch to expose that BAR to the host domain as an NTB memory window.

4. Program device-side ATU mappings

   • Map the host BAR address range to the device physical buffer base (example: device DDR at 0x40000000).
   • Verify translation entries and alignment constraints.

5. Enable doorbell and signaling

   • Configure doorbell registers and optionally IRQ routing for cross-domain notifications.

6. Sanity checks

   • Confirm link up status on both domains.
   • Confirm the host sees only the switch NTB endpoint and not devices behind the device domain.

Data path and operation

Host reads device buffer (host → device):

• Host software performs MMIO or memory-mapped access to the NTB BAR window.
• Switch ATU translates the host BAR transaction into a device-domain access to the mapped buffer.
• Device firmware or logic processes the received data and optionally signals completion via doorbell.

Device DMA reads host memory (device → host):

• Device DMA engine generates TLP read requests targeted at host physical addresses.
• ATU mapping routes those requests across the NTB to the host domain.
• The host services the read. Host software sees normal memory access without topology changes.

Validation and test results

• FPGA DMA successfully read live host memory (user and kernel space) using the NTB-mapped path in lab tests.
• Host OS required no special drivers or firmware changes.
• Common PCIe diagnostic tools observed only the NTB-capable switch endpoint. Devices in the device domain did not appear in host enumerations.

Testing notes

• Use a vendor-grade PCIe protocol analyzer to confirm expected behavior at the link and transaction layers.
• Perform timing and traffic analysis to validate that the host-side exposure window is controlled.

Limitations and deployment considerations

• Cost. NTB-capable switches and FPGA systems increase BOM cost versus direct PCIe devices.
• Complexity. ATU programming, domain partitioning, and debugging require deep PCIe expertise.
• Deployment customization. Topology, address windows, and platform differences often need per-deployment tuning.

This architecture best fits high-security research, authorized forensic operations, or specialized industrial deployments where cost and complexity are acceptable tradeoffs.

Legal and ethical disclaimer

This README documents methods intended for lawful, authorized use only. Examples include memory forensics, authorized system audits, and legitimate performance acceleration. Misuse of these techniques may violate laws and regulations.

Do not use the described methods without express authorization from the system owner. The research team disclaims liability for unauthorized or illegal activities.

Appendix & references

• PCI Express Base Specification (consult latest version from PCI-SIG)
• Vendor datasheet and register guide for the chosen PCIe switch (e.g., PLX/ Broadcom documentation)
• ATU and NTB register reference in vendor documentation
• PCIe protocol analyzer usage guides for link and transaction inspection

---

For edits, additional sections, or a conversion to a formatted whitepaper or slide deck, request the changes and specify layout preferences. if you have any questions contact me on Discord: @sqltable