|
| 1 | +# Proposal: AI-Driven Reproducer Generation Workflow |
| 2 | + |
| 3 | +## 1. Objective |
| 4 | +To design a new AI agent workflow within the syzkaller `aflow` framework (`pkg/aflow/flow/repro/repro.go`) that |
| 5 | +automatically converts a kernel crash report (and associated execution logs) into a reliable |
| 6 | +syzkaller reproducer (syzlang). |
| 7 | +The agent will leverage existing syzlang descriptions (`sys/linux/*.txt`) to ensure the generated reproducers conform |
| 8 | +to syzkaller's type system and API constraints. |
| 9 | + |
| 10 | +First step is to generate the MVP that works and allows to parallelize the work. If some tool or feature may be |
| 11 | +postponed it is better to postpone it. |
| 12 | + |
| 13 | +## 2. High-Level Architecture & Agent Loop |
| 14 | + |
| 15 | +The workflow will operate as an iterative feedback loop, utilizing the LLM's reasoning capabilities to bridge the gap |
| 16 | +between a crash signature and a functional syzlang program. |
| 17 | + |
| 18 | +1. **Context Initialization:** Ingest the kernel crash log with stack trace, |
| 19 | +target kernel information (`.config`, `kernel repo`, `kernel commit`) and |
| 20 | +the raw execution log leading up to the crash (if available from the fuzzing instance). |
| 21 | +Core dump and kcov traces will be of great help when available. |
| 22 | + * MVP will get all the available information from syzbot dashboard. Bug ID is the input. |
| 23 | +2. **Subsystem Analysis:** Identify the vulnerable subsystem (e.g., `io_uring`, `bpf`, `ext4`) based on the stack trace. |
| 24 | + * It will be needed to support requests w/o subsustem name. It is not needed for syzbot. |
| 25 | + * MVP gets subsystem information from dashboard. |
| 26 | +3. **Syzlang Contextualization:** Query the syzlang descriptions to extract the relevant syscall signatures, structs, |
| 27 | +and valid flags for the identified subsystem. |
| 28 | + * MVP passes `syzlang-search` tools (`ListDescriptions`, `GetDescriptions`) to the LLM agent, allowing it to lookup exact descriptions dynamically. |
| 29 | +4. **Draft Generation:** The LLM generates an initial candidate `.syz` reproducer. |
| 30 | +5. **Execution & Verification:** Compile and run the candidate against an instrumented kernel VM. |
| 31 | + * MVP LLMAgent uses `syz-compiler-check` and `crash-reproducer` tools to verify and execute directly in a loop. |
| 32 | + * Note: The generated crash may be different from the original one (e.g. different stack trace, but same root cause). |
| 33 | + * We need to verify that the produced crash is "very close" to the original one (e.g. same function, same type). |
| 34 | +6. **Iterative Refinement:** If the crash does not reproduce, or if there is a syzlang compilation error, the agent |
| 35 | +analyzes the failure output, tweaks the arguments/syscall sequence, and tries again (up to a defined maximum |
| 36 | +iteration limit). This iteration logic is fully offloaded to the LLM agent instruction capabilities. |
| 37 | + |
| 38 | +## 3. Required Framework Extensions |
| 39 | + |
| 40 | +To achieve this, the `aflow` framework will need new tools and actions specifically tailored for syzlang manipulation |
| 41 | +and program execution. |
| 42 | + |
| 43 | +### A. New Tools (`pkg/aflow/tool`) |
| 44 | +The MVP introduced several critical tools for the LLM agent to iterate effectively: |
| 45 | +* `syzlang-search` tools (`ListDescriptions`, `GetDescriptions`): Extracted `syzlang` definition lookup into exact, granular tools for the LLM. |
| 46 | +* `syz-compiler-check`: Validates the LLM-generated `.syz` program syntax relying on `prog.Target.Deserialize(...)`. |
| 47 | + * *Input:* Raw syzlang text. |
| 48 | + * *Output:* Success along with the strictly formatted canonical syzlang program serialized as a string, or a list of syntax/type errors. |
| 49 | +* `crash-reproducer`: Tool wrapper around `crash.Reproduce` allowing the LLM agent to trigger VM executions on the fly. |
| 50 | +* `compare-crash-signature`: Tool wrapper testing if the reproduced bug title matches the original. |
| 51 | + |
| 52 | +### B. Actions (`pkg/aflow/action`) |
| 53 | +The core MVP workflow (`repro.go`) implements a linear pipeline combining kernel building actions with reasoning and testing modules: |
| 54 | +* `kernel.Checkout` and `kernel.Build`: Ensure the vulnerable kernel image is ready. |
| 55 | +* `aflow.LLMAgent`: Configured as `crash-repro-finder`, taking responsibility for the iterative *Generate -> Compile -> Execute -> Compare* loop using the newly defined `pkg/aflow/tool` set. |
| 56 | +* `crash.Reproduce`: Pipeline action running the ultimately verified `.syz` code inside the test VM. |
| 57 | +* `aflow.Compare`: A generic variable comparison helper (refactored from `CompareCrashSignature`) confirming if the produced crash directly matches the target bug title. |
| 58 | + |
| 59 | +## 4. Implementation Plan |
| 60 | + |
| 61 | +### Phase 1: Tooling & Infrastructure (Foundation) |
| 62 | +* **Implement `SyzlangSearch` tool:** Parse the AST of `sys/linux/` and expose a search interface to the agent. |
| 63 | +* **Reuse `crash.Reproduce` action:** Reuse the logic from `pkg/aflow/action/crash` so the agent can trigger executions inside the isolated |
| 64 | +test VMs already managed by `aflow`'s checkout/build actions. Modify it if necessary. |
| 65 | + |
| 66 | +### Phase 2: Prompt Engineering & Context Management |
| 67 | +For MVP we don't care about the Context Window Optimization. |
| 68 | +* **System Prompt:** Define the persona. |
| 69 | +(e.g., *"You are an expert kernel security researcher. Your goal is to write a syzkaller program to trigger |
| 70 | +a specific bug. Use syzlang syntax strictly."*) |
| 71 | +* **Context Window Optimization:** Kernel logs and syzlang files can be large. |
| 72 | +Implement truncation and selective inclusion for dmesg and syzlang structs to avoid blowing out the token limit. |
| 73 | + |
| 74 | +### Phase 3: Workflow Implementation (`pkg/aflow/flow/repro/repro.go`) |
| 75 | +* Setup is a linear pipeline orchestrating `Checkout` -> `Build` -> `LLMAgent` -> `Reproduce` -> `Compare`. |
| 76 | +* Implement the iterative loop: The loop structure (*Generate -> Compile -> Execute -> Evaluate -> Refine*) is abstracted and delegated entirely to the `LLMAgent`'s instructions, taking advantage of syzkaller tool execution. |
| 77 | +* Implement exit conditions: Success (matching crash signature produced or tool exit rules), handled seamlessly. |
| 78 | + |
| 79 | +### Phase 4: Evaluation & Syzbot Integration |
| 80 | +* Test the workflow against historical syzbot bugs to measure the agent's success rate and iteration average. |
| 81 | + * Note: We don't need the known reproducers to measure success because the crash point is defined by the call stack. |
| 82 | + * Success is defined as triggering a crash "very close" to the original one (same root cause). |
| 83 | +* Deploy as an experimental job type on `syzbot.org/upstream/ai`. |
| 84 | + |
| 85 | +## 5. Resolved Design Decisions |
| 86 | +* **`syz-manager` MCP mode vs separate runner:** Created a dedicated `syz-aflow` command-line tool (`tools/syz-aflow`) to invoke local workflows using JSON context inputs avoiding the complexity of modifying `syz-manager` directly. |
| 87 | +* **Program verification logic:** Reused existing parsing directly via `prog.GetTarget("linux", "amd64").Deserialize(...)` embedded inside the `syz-compiler-check` tool, keeping verification reliable and fast. The tool also serializes the parsed program to return its canonical representation for downstream analysis. |
0 commit comments