DOCA Argus Service Guide

This page provides installation, configuration, and usage instructions for the DOCA Argus Service.

DOCA Argus is a DOCA service running on NVIDIA® BlueField® networking platforms, designed to immediately detect and enable response to attacks, minimizing their potential impact and risk.

The DOCA Argus framework provides real-time situational awareness and runtime threat detection by inspecting host memory using advanced memory forensics. Live machine introspection is performed at the hardware level, analyzing specific snippets of volatile host memory to monitor threats in real time without impacting system performance. DOCA Argus does not violate privacy, as information is extracted only from kernel structures.

Unlike conventional tools, Argus runs independently of the host, requiring no agents, integration, or reliance on host-based resources. This agentless, zero-overhead design enhances system efficiency and ensures resilient security in any compute environment, including bare-metal, virtualized, containerized, and multi-tenant infrastructures. By operating outside the host, isolated in its own trust domain, DOCA Argus remains invisible to attackers—even if the system is compromised.

Cybersecurity professionals can integrate DOCA Argus with SIEM, SOAR, and XDR platforms for continuous monitoring, incident response, and automated threat mitigation, extending existing capabilities into AI infrastructure environments.

NVIDIA BlueField provides built-in, data-centric protection for AI workloads at scale. Combining BlueField’s acceleration capabilities with DOCA Argus’ proactive threat detection enables cloud service providers and enterprises to secure AI factories without compromising performance or efficiency.

A single BlueField card with DOCA Argus can monitor an entire node.

Raw activities are collected from host memory and used to outline the operational state of a workload. DOCA Argus uses DOCA DMA to access and inspect host memory. Accessed memory is decoded into logical information (e.g., process and thread data). A policy engine processes these activities, filtering irrelevant content and reporting only meaningful data.

Key concepts:

• Event – One or more meaningful activities that represent the current recorded state. Provides situational awareness.

• Alert – One or more meaningful activities that indicate an immediate threat or impact requiring investigation or response.

Events, alerts, and system activity messages are formatted in JSON and syslog, and logged locally. Data can be exported via Fluent Bit integration for delivery to security platforms and data lakes.

• Operates only on DPU targets (BlueField-2 or later).

• Requires DPU mode (see BlueField Modes of Operation).

• Requires firmware version 24.35.0388 or later.

• Supported BlueField image versions: 4.11.0 or later.

• Argus service container must run in privileged mode to enable full-system DMA reads.

• Tested only on KVM hypervisors.

• Supports Linux-based OSs (bare-metal, virtualization, containers). Windows OS support planned.

• Kata Containers are supported only if NVIDIA-DPU support is enabled.

• Supports only x86 64-bit architectures. AARCH64 support planned.

1. Configure BlueField firmware. On BlueField, configure the PF BAR register:

   Copy

   Copied!

               
   
               
   dpu> mlxconfig -d /dev/mst/<mst_device> s PF_BAR2_SIZE=2 PF_BAR2_ENABLE=1
           

   Replace <mst_device> with:

   • mt41686_pciconf0 for BlueField-2

   • mt41692_pciconf0 for BlueField-3

2. Enable IOMMU passthrough (only if not already enabled).

   Note

   Skip unless DMA fails with messages similar to the following in dmesg:

   Copy

   Copied!

               
   
               
   mlx5_core 0000:81:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT ...]
           

   1. Edit GRUB config:

      Copy

      Copied!

                  
      
                  
      host> sudo vim /etc/default/grub
              

   2. Update GRUB_CMDLINE_LINUX_DEFAULT with :

      Copy

      Copied!

                  
      
                  
      iommu=pt <intel/amd>_iommu=on
              

   3. Apply changes:

      • For Ubuntu:

        Copy

        Copied!

                    
        
                    
        sudo update-grub
                

      • For CentOS/RHEL:

        Copy

        Copied!

                    
        
                    
        sudo grub2-mkconfig -o /boot/grub2/grub.cfg
                

   4. Reboot.

3. Prepare the target system. Argus should auto-detect target config files. If not, configure manually:

   1. Download OS debug symbols.

      • For Ubuntu:

        Copy

        Copied!

                    
        
                    
        sudo tee /etc/apt/sources.list.d/ddebs.list << EOF
        deb http://ddebs.ubuntu.com/ $(lsb_release -cs) main restricted universe multiverse
        deb http://ddebs.ubuntu.com/ $(lsb_release -cs)-updates main restricted universe multiverse
        deb http://ddebs.ubuntu.com/ $(lsb_release -cs)-proposed main restricted universe multiverse
        EOF
        sudo apt install ubuntu-dbgsym-keyring
        sudo apt-get update
        sudo apt-get install linux-image-$(uname -r)-dbgsym
                

      • For CentOS/RHEL:

        Copy

        Copied!

                    
        
                    
        sudo yum install --enablerepo=base-debuginfo \
          kernel-devel-$(uname -r) \
          kernel-debuginfo-$(uname -r) \
          kernel-debuginfo-common-$(uname -m)-$(uname -r)
                

   2. Install DOCA on target or copy doca_apsh_config.py from BlueField.

   3. Create JSON files:

      Copy

      Copied!

                  
      
                  
      cd /opt/mellanox/doca/tools/
      pip3 install psutil pdbparse
      python3 doca_apsh_config.py --files memregions symbols --os <windows/linux> --path <path to dwarf2json>
      cp /opt/mellanox/doca/tools/*.* <shared-folder>
      dpu> scp <shared-folder>/* <path-to-app-shield-binary>
              

      Note

      dwarf2json must be installed separately from GitHub. Repeat this step after kernel updates.

• For DPU container deployment, see DOCA Container Deployment Guide.

• For Argus-specific deployment, refer to the service container’s page.

• For offline deployment (no Internet access), see the Offline Deployment section in DOCA Container Deployment Guide..

Argus configuration is managed via SERVICE_CONFIG_FILE in the container YAML.

Service

• Immediate shutdown – Terminate immediately on SIGINT/SIGTERM (skip graceful shutdown).

• Service log level – DOCA logging verbosity (default 50 = INFO). Options: 10=DISABLE, 20=CRITICAL, 30=ERROR, 40=WARNING, 50=INFO, 60=DEBUG, 70=TRACE.

• System scanner sleep time – Delay between scans (s = seconds, m = minutes, ms = milliseconds).

DOCA Argus Configuration

• Auto Scan – Scan all available systems unless systems section is defined.

• Default – Default configs applied if not overridden in systems.

• Systems – List of monitored systems with overrides.

Per-System Configurations

• Representor ID – VU ID of VF/PF to track.

  • PF –

    Copy

    Copied!

                
    
                
    host> lspci -vv -s <PF_pci_address> | grep VU | cut -d " " -f 4
            

  • VF – Append VF<x> to PF’s VU ID. Example: MT2333XZ06YAMLNXS0D0F0VF1

• Memory regions path – JSON file path (or auto) for host OS memory map.

• OS symbol path – JSON file path or directory (or auto).

• OS type – Linux or Windows.

• DMA device name – Matches representor ID. List devices:

  Copy

  Copied!

              
  
              
  dpu> ibv_devinfo | grep 'hca_id' | awk '{print $2}'
          

• Service log level – Overrides service log verbosity.

• SDK log level – Sets SDK logging verbosity.

• Limits – Set max values for string length, processes, file handles, threads, VMAs.

• Events

  • Container filter – Include/exclude containerized processes.

  • SBOM – List SHA signatures of approved executables/libraries.

Collection

• Events – Enable/disable per event type.

Output

• Log events to stdout – Enable standard output logging.

• Log folder path – Directory for file logs.

• Log threshold size – Rotate logs at this size.

• Log max files count – Max number of rotated logs.

• Telemetry address – Aggregator address.

• Telemetry tag – Tag for Fluent Bit integration.

• Telemetry format – JSON or syslog.

• Telemetry user data – Custom user-defined metadata.

Standard Output

Displays only important service logs, such as version information, successful startups, and error messages on failures.

Debug Log Output

Provides a complete log output for debugging, including partial event data, trace logs, collection failures, and more. These logs are stored in the /var/log/doca_argus/ directory.

Event Log Output

Stores a complete event log in JSON format in the log folder path specified in the service configuration file. For local log storage, log rotation is handled by Linux logrotate. You can override the default configuration in /etc/cron.d/logrotate and /etc/logrotate.d/argus.

Telemetry Output

The Argus service can produce telemetry records in JSON or syslog formats.

By default, telemetry is disabled. To enable it, set the telemetry_address parameter in the service configuration file and ensure telemetry_tag matches the tag used in your Fluent Bit configuration.

Telemetry has been tested with Fluent Bit integration, which should run independently from the Argus service.

For example, running Fluent Bit locally on the DPU alongside the Argus service can be configured with the following input section:

            

            
[INPUT]
    Name                  tcp
    Tag                   <your preferred tag>
    Listen                0.0.0.0
    Port                  24224
    Format                json
        

If you are using Splunk, add the following encapsulation filter to the Fluent Bit configuration file:

            

            
[FILTER]
    Name                  nest
    Match                 *
    Operation             nest
    Wildcard              *
    Nest_under            event
        

Fluent Bit is flexible and can integrate with many output destinations.

The following is a basic example that forwards telemetry data to Elasticsearch:

            

            
[INPUT]
    Name                  tcp
    Tag                   elastic_forward_input
    Listen                0.0.0.0
    Port                  24224
    Format                json
 
[SERVICE]
    Log_Level             info
 
[OUTPUT]
    Name                  es
    Match                 *
    Host                  <elasticsearch_ip>
    Port                  <elasticsearch_port>
    Index                 argus
    Suppress_Type_Name    On
    Log_Level             info
        

To run Fluent Bit with this configuration:

            

            
docker run --rm --net=host -v <path_to_fluentbit_conf_file>:/fluent-bit/etc/fluent-bit.conf --name fluent_bit -it fluent/fluent-bit
        

Refer to the Fluent Bit manual for details on additional output plugins and configurations.

The DOCA Argus service generates structured output messages containing detailed metadata, system information, and activity data.

The following table describes the fields included in each message:

The following example is a JSON message that describes the data that produced for each event and alert:

            

            
{
    "vendor_name": "NVIDIA",
    "product_name": "DOCA_ARGUS",
    "product_version": "<version>",
    "message_type": "<EVENT | ALERT | SYSTEM_ACTIVITY>",
    "severity": "<INFO | ERROR | WARNING | MEDIUM | HIGH | CRITICAL>",
    "schema_version": "1.0",
    "message_id": "<unique_message_id>",
    "occurred_message_timestamp_utc_ms": "1747052933345",
    "occurred_message_display_time_local_rfc3339": "2025-05-12T12:28:53.458+00:00",
    "occurred_message_display_time_utc_rfc3339": "2025-05-12T12:28:53.458Z",
	"message_timezone": "UTC",
	"message_timezone_offset": "0",
    "user_data": "NONE",
    "bluefield_system_information": {
        "bluefield_networking_interfaces": {
            "0": {
                "bluefield_network_interface_name": "<>",
            	"bluefield_network_interface_mac_address": "<>",
            	"bluefield_network_interface_ipv4_address": "<>"
				"bluefield_network_interface_ipv6_address": "<>"
            },
             "1": {
                "bluefield_network_interface_name": "<>",
            	"bluefield_network_interface_mac_address": "<>",
            	"bluefield_network_interface_ipv4_address": "<>"
				"bluefield_network_interface_ipv6_address": "<>"
            }, 
			"..."
        }
    },
    "workload_information": {
        "unique_identifier": "<>",
        "os_version": "<>",
        "workload_networking_interfaces": {
            "0": {
                "network_interface_name": "<>",
                "network_interface_mac_address": "<>"
				"network_interface_ipv4_address": "<>",
 				"network_interface_ipv6_address": "<>",                 
            },
             "1": {
                "network_interface_name": "<>",
                "network_interface_mac_address": "<>"
				"network_interface_ipv4_address": "<>",
 				"network_interface_ipv6_address": "<>",                 
            }, 
            "..."
        }
    },
    "activity_data": {
        "name": "<the name of the EVENT | ALERT | SYSTEM_ACTIVITY>",
        -- Activity Details to follow per the type of EVENT | ALERT | SYSTEM_ACTIVITY --
    }
}
        

DOCA Argus monitors workload and system behavior in real time, generating alerts, events, and system activity messages that provide visibility into security-relevant activities, operational state changes, and detected anomalies. These messages are categorized by type, severity, and activity name, with descriptions to help identify their purpose and implications.

The tables in this section outline the supported activities that Argus can detect, covering a broad range of categories including process creation and termination, network connections, execution of binaries and libraries, process memory changes, file handle operations, thread creation and termination, container lifecycle events, and key system service milestones or errors.

Creation or Modification of System Processes

Network Connections

Executed Binaries and Loaded Libraries (Software Bill of Materials/Process Attestation)

Process Memory

File Handles

Threads

Containers

System Events

The following attributes are currently provided for processes, TCP network connections, file handles, threads, process memory, and SBOM/process attestation.

For requests regarding the extraction of additional attributes, please contact NVIDIA.

Processes

Threads

File Handles

TCP Network Connections

Process Memory

Executed Binaries and Loaded Libraries (Attestation)