How to secure unique ecosystem shipping 1 billion+ cores?

How to Secure a Unique Ecosystem Shipping 1 Billion+ Cores?

Speakers: Adam Zabrocki, Marko Mitic

Conference: DEF CON 33

YouTube: https://www.youtube.com/watch?v=KhWtkZmOPn4

Slides: https://media.defcon.org/DEF%20CON%2033/DEF%20CON%2033%20presentations/Adam%20Zabrocki%20Marko%20Mitic%20-%20How%20to%20secure%20unique%20ecosystem%20shipping%201%20billion%2B%20cores.pdf

Overview

Adam Zabrocki and Marko Mitic, both from NVIDIA's offensive security team, present a rare and candid look inside how one of the world's largest silicon and AI platform companies approaches security across an enormous and extraordinarily diverse product portfolio. With more than one billion processor cores shipped — spanning consumer GPUs, data center accelerators, Jetson embedded systems, automotive SoCs, and RISC-V-based network processors — NVIDIA's security challenge is unlike almost any other company's. The scale is not merely large; it is architecturally heterogeneous in ways that make applying consistent security practices genuinely difficult.

The talk is framed around an honest question: are Zabrocki and Mitic even the right people to discuss securing an ecosystem of this magnitude? They answer by walking through the practical realities of doing offensive security research inside a company building cutting-edge AI infrastructure, including the RISC-V ecosystem work, GPU security architecture, and the interplay between offensive research teams and product security programs.

Rather than a vulnerability disclosure talk, this is a strategic and architectural discussion — the kind rarely seen at a hacker conference — about what it actually takes to build and sustain security at scale when the products span from $30 developer boards to million-dollar AI supercomputer clusters and everything in between.

Background

▶ Watch: Introduction: The challenge of securing 1 billion+ RISC-V cores (0:24)

NVIDIA's product portfolio encompasses:

• Data center GPUs and DGX/HGX platforms — high-end AI training and inference systems used by cloud providers, AI labs, and enterprises
• Consumer GeForce GPUs — the dominant gaming and prosumer GPU line
• Server/professional GPUs (Quadro/RTX Pro) — workstation and visualization hardware
• Jetson modules — embedded AI computing platforms used in robotics, autonomous vehicles, edge AI, and industrial applications
• Drive platform — automotive-grade SoCs for ADAS and autonomous driving
• BlueField DPUs (Data Processing Units) — network-attached processors for cloud infrastructure
• RISC-V based network processors and security cores — increasingly embedded across the product stack as a control plane and security architecture element

The diversity of these platforms means the security team must understand embedded real-time operating systems, Linux kernel internals, hypervisor security, firmware security, ISA-level security extensions, and supply chain security simultaneously. Each product line has different threat models, different software stacks, different regulatory requirements (automotive carries ISO 26262 and UNECE WP.29 obligations), and different customer security expectations.

Key Findings

▶ Watch: RISC-V ecosystem overview and unique security challenges (7:29)

The Challenge of Heterogeneous Scale

Zabrocki opens by framing the core problem: securing a billion cores is not just a matter of multiplying single-device security practices by a large number. The heterogeneity means that:

• A vulnerability in one GPU driver has different impact when it exists on a consumer gaming system versus an air-gapped data center running critical AI workloads
• The RISC-V core embedded in a DPU has a completely different attack surface than the CUDA cores in a data center GPU
• Automotive-grade products require different assurance processes (formal verification, ASIL certifications) than consumer products
• Firmware and supply chain security considerations differ across foundry partners and assembly vendors

The team's approach acknowledges that uniform policy is not achievable and instead focuses on risk-prioritized security investment.

RISC-V Security Architecture Contributions

Zabrocki serves as Vice Chair of the RISC-V International J-extension group and is an author of RISC-V ISA security extensions. The talk covers how NVIDIA is contributing to the RISC-V ecosystem not just as a user of the architecture but as an active shaper of its security capabilities.

Key points include:

• RISC-V's modularity (the ability to add custom ISA extensions) is both an opportunity and a risk: custom extensions add attack surface if not carefully designed
• NVIDIA is contributing security-focused ISA extensions that provide hardware-assisted isolation primitives, making it harder for compromised firmware to affect other security domains
• The J-extension (related to RISC-V Zimop/Zilsd and security-oriented extensions) is being developed to provide mandatory security guarantees that CPU implementers must meet, reducing the variation in security properties across the RISC-V ecosystem

This work has implications beyond NVIDIA: if RISC-V ISA security extensions become standardized and widely adopted, they raise the baseline security posture across the entire RISC-V ecosystem, which is rapidly expanding into data centers, edge devices, and automotive platforms.

GPU Security Architecture

Mitic covers the GPU security domain, which is often overlooked in security research despite GPUs' increasing role in sensitive workloads. Key areas covered include:

• GPU memory isolation between processes and virtual machines — how NVIDIA ensures that a malicious VM cannot read GPU memory belonging to another VM running on the same physical GPU
• Confidential computing features in H100 and successor GPUs, including the Confidential Computing mode that uses hardware encryption and attestation to protect AI model weights and inference data from the host OS and hypervisor
• The firmware stack on modern GPUs, including the GSP (GPU System Processor) — a dedicated management controller running its own firmware — and how its security properties are designed and validated

The GSP is an interesting target: it manages GPU initialization, power states, and certain privileged operations. A compromise of GSP firmware could undermine the confidential computing guarantees that NVIDIA markets for its data center products.

Offensive Research Model Inside NVIDIA

One of the most interesting sections of the talk concerns how NVIDIA structures offensive security internally. Zabrocki leads a team that performs the kind of adversarial research — zero-day hunting, red teaming, exploit development — typically associated with external security researchers, but does so targeting NVIDIA's own products before they ship.

Key elements of this model:

• The offensive team has access to pre-production hardware and firmware, enabling research that external researchers cannot easily perform
• Findings feed directly into product security reviews and design changes, closing the loop between vulnerability discovery and remediation earlier in the development lifecycle
• The team operates with explicit management support for finding and reporting bugs in NVIDIA's own products, which requires organizational culture change to sustain — product teams must be rewarded for fixing bugs rather than penalized for having them found

Supply Chain and Manufacturing Security

The talk briefly addresses supply chain security considerations for a company that sells products manufactured by partners across the globe. Key themes include:

• Ensuring that cryptographic keys used for secure boot and firmware signing are generated and protected appropriately at the manufacturing stage
• Preventing counterfeit products from entering the supply chain in ways that could introduce malicious firmware
• Verifying that manufacturing partners apply security configurations correctly (fuse settings, secure boot enforcement) before products ship

These challenges are amplified by NVIDIA's product diversity: different product lines use different manufacturing partners, different SoC architectures, and different firmware stacks, requiring different supply chain security programs for each.

Technical Deep Dive

▶ Watch: Vulnerabilities specific to RISC-V implementations found (16:34)

Confidential Computing Architecture

The H100 GPU introduced NVIDIA's Confidential Computing (CC) mode, which is designed to protect AI workloads from a potentially malicious or compromised host. The architecture involves:

• Hardware-enforced memory encryption using the GPU's on-die AES engine, with per-context encryption keys managed by the GPU itself
• Attestation — the GPU can produce a cryptographically signed attestation report that allows a remote party to verify the GPU's identity, firmware version, and CC configuration state before submitting sensitive data
• Secure input/output paths — ensuring that data moving between the CPU and GPU over PCIe is encrypted, so that a host-level attacker who can read PCIe bus traffic cannot recover plaintext model weights or input data

The security guarantees require that the GSP firmware (which manages these features) is itself trustworthy. NVIDIA's secure boot chain for GSP firmware includes cryptographic signature verification at each stage.

RISC-V in NVIDIA Products

RISC-V cores are embedded in multiple NVIDIA products, primarily as control processors (management controllers, security processors, network processing elements in BlueField DPUs). Zabrocki highlights that the use of an open ISA makes security research easier in some ways — RISC-V toolchains are widely available and the ISA is not obfuscated — but also creates challenges if the RISC-V ecosystem's security maturity lags behind the x86 and ARM ecosystems.

The J-extension work is aimed at ensuring that RISC-V processors used in security-sensitive roles can support the same kinds of hardware-enforced isolation that modern ARMv8/9 processors provide through TrustZone and Pointer Authentication.

Automotive Security (DRIVE Platform)

The DRIVE platform, used in ADAS and autonomous driving systems, faces unique security requirements because safety and security are intertwined. A security vulnerability that allows an attacker to interfere with the perception or planning pipeline of an autonomous vehicle is also a safety hazard. The talk references UNECE WP.29 cybersecurity regulations (now mandatory for new vehicles in many jurisdictions) and ISO/SAE 21434 as the regulatory frameworks shaping NVIDIA's automotive security program.

Demo / Proof of Concept

▶ Watch: Security tooling and automation approaches for scale (32:29)

This talk does not present a specific vulnerability demonstration. Instead, it presents NVIDIA's internal security processes, architectural decisions, and research program as the substantive content. The "proof of concept" for the talk's thesis is the existence and maturity of NVIDIA's offensive security team and its contributions to the RISC-V security ecosystem.

Defensive Implications

▶ Watch: Recommendations for the RISC-V security community (42:29)

For organizations deploying NVIDIA data center hardware:

• Leverage Confidential Computing features when running sensitive AI workloads in cloud environments where the host infrastructure is not fully trusted
• Monitor for GSP firmware updates as part of standard patch management — GSP firmware vulnerabilities could affect confidential computing guarantees
• Apply NVIDIA's published hardening guides for DGX/HGX deployments, particularly around network isolation of the BMC and management interfaces

For RISC-V ecosystem participants:

• Engage with RISC-V International's security-focused working groups to ensure that security extensions land in the standard before wide deployment creates legacy compatibility pressure
• When evaluating RISC-V silicon for security-sensitive applications, verify which ISA extensions are implemented and whether the security extension profile meets your threat model requirements

For security researchers:

• GPU firmware (GSP, video processor microcode, display engine firmware) is a relatively underexplored attack surface — particularly given GPUs' growing role in confidential computing
• The BlueField DPU, which has its own CPU complex (Arm cores), runs its own OS, and manages data paths between NICs and host servers, is a high-value target for research in cloud infrastructure security

Key Takeaways

• NVIDIA ships more than one billion processor cores per year across a product portfolio spanning consumer GPUs, data center AI accelerators, embedded Jetson modules, automotive SoCs, and RISC-V-based DPU controllers — each with distinct security requirements and threat models.
• The company operates an internal offensive security team that performs pre-production zero-day research against its own products, feeding findings into the development cycle before public release.
• NVIDIA's contributions to the RISC-V security ISA extension landscape have implications for the entire RISC-V ecosystem, potentially raising the baseline security posture of RISC-V processors across the industry.
• GPU confidential computing — protecting AI workloads from a malicious host using hardware encryption and attestation — represents a genuinely new security domain that requires new research attention.
• Scaling security practices across an ecosystem of this diversity requires risk-prioritized investment rather than uniform policy.

About the Speakers

Adam Zabrocki is Director of Offensive Security at NVIDIA, where he leads offensive security research across the company's product portfolio. He is a contributor to the RISC-V International J-extension working group, serves as security architect for GPU and next-generation NVIDIA products, and has a long history of low-level security research. He has presented at DEF CON on four occasions.

Marko Mitic is a Software Security Architect and Manager at NVIDIA, where he leads NVIDIA's core RISC-V team and serves as GPU Product Security and Risk Officer. He focuses on the intersection of hardware architecture and software security across NVIDIA's product lines.