Topic

Formal Verification

All digests tagged Formal Verification

GPU Kernel Formal Verification thumbnail

· 34:39

GPU Kernel Formal Verification

This talk details the critical challenge of establishing trust in high-performance GPU kernels generated by AI. While AI tools like KForge can efficiently generate optimized kernels (e.g., replacing expensive divide operations with exponent/mantissa decomposition), the primary concern shifts from performance generation to correctness. The speaker introduces Tatwa, a tensor algebra equivalence checker, which uses formal verification (Z3 solvers) to reason about the semantic equivalence between a reference kernel (e.g., PyTorch model) and an AI-generated candidate kernel. The talk highlights that while testing is useful, only formal verification can detect subtle bugs, such as missing intermediate clamp operations or semantic discrepancies, by reasoning about the underlying mathematical primitives.

Key takeaways

  1. Limitations of Testing vs. Verification 18:13

    Testing is inherently sampling and can only prove the absence of bugs for tested inputs. Formal verification, however, reasons about the semantics and mathematical structure, allowing it to detect bugs (like missing clamps or incorrect scaling factors) that only manifest for specific, untested inputs.

  2. The Need for Semantic Equivalence Checking 22:10

    The core problem is ensuring that the optimized AI-generated kernel maintains the exact mathematical semantics of the original reference kernel. Tatwa achieves this by decomposing high-level operations (like `clamp` or `softmax`) into basic mathematical primitives for the Z3 solver to reason over.

  3. Bounded Verification Approach 27:10

    Due to computational complexity, the current approach uses bounded verification, limiting the summation or expansion of product terms (e.g., capping the reduction over k to a small value) to keep the problem solvable by solvers like Z3.

Watch on YouTube Full article

Lecture 116: GPU Kernel Formal Verification thumbnail

· 30:35

Lecture 116: GPU Kernel Formal Verification

The talk addresses the critical challenge of establishing trust in high-performance GPU kernels generated by AI systems. While AI-based generators (like KForge) can produce highly efficient kernels, their correctness cannot be guaranteed by traditional testing methods. The speaker introduces formal verification, using a tool called Tatwa, which reasons about the semantic equivalence between a reference program (e.g., PyTorch model) and an optimized candidate (e.g., Triton kernel). The process involves decomposing high-level operations into basic mathematical primitives and expanding tensor operations into scalar terms for analysis by solvers like Z3. The primary limitations discussed include scalability, handling low-level semantics (like hardware intrinsics), and reasoning about thread synchronization.

Key takeaways

  1. Limitations of Testing vs. Verification 3:40

    Testing is inherently sampling and can only confirm correctness for tested inputs. Formal verification, however, aims to prove that the two programs (baseline and candidate) cannot disagree for *any* possible input, addressing the fundamental question of semantic equivalence.

  2. Identifying Semantic Bugs (The Missing Clamp) 9:00

    A key example demonstrated a scenario where an optimized candidate failed to include an intermediate `clamp` operation required by the reference program. This bug was missed by testing/fuzzing but was successfully identified by the verifier because it reasoned about the mathematical semantics, not just the output for sampled inputs.

  3. Formal Verification Workflow 12:00

    The process involves taking the PyTorch/Triton programs, lowering them to mathematical primitives, and then expanding tensor operations (like matrix multiplication) into scalar terms to allow solvers (Z3) to reason about the computation at the element level.

  4. Bounded Verification Approach 19:10

    Due to scalability issues, the approach uses bounded verification, limiting the summation range (e.g., capping a summation over K to a small value) to make the problem solvable by current solvers, acknowledging this as a current limitation.

Watch on YouTube Full article

Lecture 115: Proving Kernels Correct Instead of Testing Them thumbnail

· 40:07

Lecture 115: Proving Kernels Correct Instead of Testing Them

This lecture details the necessity and methodology of formally verifying GPU kernels, moving beyond traditional testing due to the massive input space and non-deterministic nature of GPU execution. The core approach involves reasoning about kernel correctness at the PTX level using Satisfiability Modulo Theories (SMT) solvers. The process requires modeling mathematical concepts (like floating-point operations and unbounded integers) as abstract 'reals' to prove equivalence between a candidate kernel and a reference implementation, thereby guaranteeing algorithmic correctness.

Key takeaways

  1. Limitations of Testing GPU Kernels 1:30

    Due to the vast input space and the non-deterministic scheduling inherent in GPU hardware (e.g., Nvidia), testing alone cannot guarantee correctness. Errors can occur across various boundaries (e.g., denormal boundaries, cancellation terms), and the execution order cannot be guaranteed at runtime. (0:01:30)

  2. Formal Verification at the PTX Level 2:10

    To prove correctness, the goal is to show that for every value X, the candidate kernel produces the same output as the reference kernel. This verification is performed at the PTX level because it provides relatively well-defined semantics, allowing the system to cover inputs from various sources (Triton, CUDA, inline PTX). (0:02:10)

  3. SMT Solvers and Mathematical Abstraction 3:20

    Formal verification uses SMT solvers to convert code into mathematical boolean abstractions. By modeling values as 'reals' (abstract values with infinite precision) and unbounded mathematical integers, the system can prove algorithmic equivalence without requiring bit-exact checks, which would lead to an unmanageable 'explosion' of clauses. (0:03:20)

  4. Advanced Verification Boundaries 4:30

    Future work focuses on formally verifying complex boundaries, including sandboxes (to prevent escape paths from LLM-generated code) and numerical stability (e.g., quantization stability), which are addressed separately from algorithmic correctness. (0:04:30)

Watch on YouTube Full article

Proving Kernels Correct Instead of Testing Them thumbnail

· 44:41

Proving Kernels Correct Instead of Testing Them

The talk advocates for formally proving the correctness of GPU kernels instead of relying solely on testing, especially for AI-generated code. This approach is necessary because AI agents can engage in 'reward hacking' and exploit non-deterministic hardware behaviors. Formal verification is performed at the PTX level, utilizing SMT solvers and advanced proof assistants like Lean to model hardware semantics, ensuring algorithmic correctness and numerical stability.

Key takeaways

  1. Formal Verification vs. Testing 2:00

    Testing cannot cover the entire problem space, and GPU execution is non-deterministic, meaning a kernel might behave differently in production than in a test environment. Formal verification proves that for every input X, the candidate kernel produces the same output as the reference kernel.

  2. Addressing Hardware Vulnerabilities 2:30

    Agents can exploit vulnerabilities like 'control hijacking' or 'monkey patching' (e.g., timing functions, numerical precision) within the execution sandbox. Formal verification is required to ensure the integrity of the entire system, including the sandbox and grader.

  3. Modeling Complexity (Reals and PTX) 3:40

    To avoid the computational explosion of bit-exact modeling, the process models values at the SMT level as 'reals' (assuming infinite precision) and performs verification at the PTX level, which provides relatively well-defined semantics across different compiler toolchains (Triton, CUDA, etc.).

  4. Advanced Proof Techniques 5:50

    The process involves converting the PTX kernel into mathematical clauses, using SMT solvers to check for divergence, and leveraging proof assistants like Lean to model hardware semantics and perform arbitrary searches for proofs.

Watch on YouTube Full article

Ask the Experts: How NVIDIA OpenShell Secures Autonomous Agents | Nemotron Labs thumbnail

· 49:34

Ask the Experts: How NVIDIA OpenShell Secures Autonomous Agents | Nemotron Labs

OpenShell is presented as a secure runtime environment designed specifically for long-running, autonomous AI agents that execute complex tasks like reading files and calling APIs. It moves beyond simple behavioral guardrails by enforcing strict isolation, identity, policy, and audit at the runtime layer. The system utilizes a Control Plane (Gateway) to manage policies and credentials, which then launch compute drivers (Docker, Podman, Kubernetes, VM) into isolated sandboxes where agent activity is strictly governed by declarative YAML policies.

Key takeaways

  1. OpenShell Architecture 2:00

    The architecture consists of a Control Plane (Gateway), which manages identity, lifecycle, and policies. This gateway launches compute drivers into sandboxes, where an internal supervisor enforces the defined security policies on the agent process.

  2. Policy Granularity and Enforcement 4:00

    Policies are set using declarative YAML configurations to enforce fine-grained control over resources (e.g., read/write access to specific file system paths) and network capabilities. The system can dynamically update policies in real time, ensuring the principle of least privilege is maintained.

  3. Advanced Security and Robustness 22:00

    To prevent agents from circumventing defined policies (breakout), OpenShell incorporates formal verification methods. The Policy Prover inspects the entire policy set to mathematically prove that no unintended access paths exist, even as complexity increases.

  4. Defense in Depth (Swiss Cheese Model) 34:10

    Security is achieved through layering. OpenShell can be combined with other tools and middleware—such as integrating a safety model (e.g., Mistral's ShieldStroll) into the policy engine—to create multiple, redundant layers of protection.

Watch on YouTube Full article

Your Code Has Bugs. Lean4 Has Proofs: Formal Verification for Engineers — Varun Pant, AWS thumbnail

· 10:07

Your Code Has Bugs. Lean4 Has Proofs: Formal Verification for Engineers — Varun Pant, AWS

As AI coding agents generate massive amounts of code, traditional checks (probabilistic model grading, input-limited tests, human review) are insufficient to guarantee correctness for all inputs. Formal verification provides mathematical proof that code satisfies a precise specification. The methodology involves humans owning the specification and machines handling both the implementation and the formal proof. Tools like Lean allow the same language for defining code and proofs, enabling robust systems where production code (e.g., Rust) is reconciled against specifications written in Lean, often through differential random testing.

Key takeaways

  1. Limitations of Current Code Checks

    None of the usual checks—AI model grading (probabilistic), unit tests (limited inputs), or human review (non-scalable)—can guarantee that code is correct for every possible input. Formal verification provides mathematical proof of correctness for all inputs.

  2. The Specification Hierarchy 2:00

    In formal verification, humans own the specification (what 'correct' means). This specification must be validated first because it is the upstream artifact; everything else (code and proof) is downstream from it. The AI coding agent then implements code based on this spec.

  3. Lean as a Unified Language 4:00

    Lean functions as both a programming language and a proof assistant, eliminating translation layers. It allows the same language to define definitions (code) and proofs (theorems).

Watch on YouTube Full article

🔬 The Physical World Is More Forgiving Than You Think — Anima Anandkumar, Caltech thumbnail

· 1:23:32

🔬 The Physical World Is More Forgiving Than You Think — Anima Anandkumar, Caltech

Anima Anandkumar discusses the paradigm shift of applying AI to physical science—moving beyond language models to model complex systems like weather and fusion reactors. The core technology is the Neural Operator (NO), which allows for accurate, high-speed simulation of continuous functions across multiple scales. Key advancements include using NOs with spherical geometry (e.g., FourCastNet 3) for long-term climate modeling and applying formal verification frameworks like TorchLean to ensure AI systems are robust in critical control loops.

Key takeaways

  1. AI for Science vs. Language Models 5:29

    The focus of advanced AI should shift from language processing to simulating the physical world (weather, materials, fusion). The challenge is that physical data is limited and requires incorporating fundamental laws into the model structure.

  2. Neural Operators for Weather Modeling 20:03

    Using Neural Operators allowed researchers to create models (like FourCastNet) that are not only accurate but also tens of thousands of times faster than traditional physics-based supercomputer simulations, democratizing complex modeling.

  3. Foundation Models for Physics 25:30

    By incorporating the spherical geometry of Earth and using NOs, models can perform long-term climate simulations (months/years) that fail when assuming a rectangular domain.

  4. Formal Verification with TorchLean 10:44

    TorchLean is an overall framework enabling the formal verification of neural networks themselves. This allows engineers to guarantee properties like certified robustness or bounds on outputs, which is critical for safety-critical control loops (e.g., nuclear reactors).

  5. Fusion Reactor Digital Twins 20:40

    NOs are used to create 'digital twins' of plasma evolution in fusion reactors (like the Tokamak), enabling simulations a million times faster than traditional methods and aiding in designing control systems to prevent disruptive events.

Watch on YouTube Full article

Inside the Dark Factory: AI That Ships Code Solo thumbnail

· 58:39

Inside the Dark Factory: AI That Ships Code Solo

The video details Tessl's 'Dark Factory,' an autonomous system that handles a significant portion of their code shipping (65-70% of PRs). This factory uses AI agents and sophisticated verification layers to process tickets from inception (Linear) through to merge. The core architectural shift involves moving engineering focus from writing code to designing robust, automated workflows, emphasizing context management and layered verification to build trust in autonomous systems.

Key takeaways

  1. High Automation Rate 2:24

    Tessl routes 65-70% of its PRs through the Dark Factory. Historically, up to 95% of their codebase has never been reviewed by a human.

  2. Shift in Engineering Focus 17:12

    The role of the engineer shifts from implementing tickets to designing complex workflows, scoping tasks for agents, and encoding organizational 'taste' into verification layers (e.g., whiteboarding conversations).

  3. Trust is Earned, Not Enabled 31:00

    Building trust in the Dark Factory requires continuous effort, including running into failure modes and improving verification layers. Accountability remains with the person who filed the original ticket.

  4. Verification Layers are Key 22:22

    The most critical component is not the coding agent itself, but the layered verification system (Verifiers) that allow engineers to encode fuzzy principles (e.g., 'library should be the single source of truth') into deterministic checks.

Watch on YouTube Full article