{"owner":"google","repo":"syzkaller","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":["GEMINI.md"],"skills":{"GEMINI.md":"# syzkaller - Context for Gemini\n\n## Project Overview\n`syzkaller` is an unsupervised, coverage-guided kernel fuzzer. It is a hybrid\nsystem consisting of a **Go-based manager** (running on a host) and a **C++\nexecutor** (running inside the target VM).\n\n-   **Primary Language:** Go (Manager, Tools), C++ (Executor).\n-   **Architecture:**\n    -   `syz-manager`: Orchestrates the fuzzing process, manages corpus, and monitors VMs.\n    -   `syz-executor`: Runs inside the VM, executes test programs via syscalls, and collects coverage.\n    -   `syz-ci`, `syz-hub`, `dashboard`: Infrastructure for continuous fuzzing and reporting.\n\n## Building and Testing\n\nPrefer to use the `syz-env` Docker container to build the compontents and run\ntests. There's a `./tools/syz-env` script that will start a container and run\nthe given command inside it.\n\nSome reference commands:\n* Build everything: `CI=true ./tools/syz-env make`.\n* Run a linter: `CI=true ./tools/syz-env make lint`.\n* Run a test: `CI=true ./tools/syz-env go test ./package -run TestName`.\n* Formatter: `CI=true ./tools/syz-env make format` (runs `gofmt`, `clang-format`, etc).\n\nNote the `CI=true` part - otherwise the commands may not run in your environment.\n\nWhen running tests (especially in `./prog` and `./pkg/csource`) prefer to run\nindividual tests you have affected, otherwise it may take a lot of time. Some\npackages also offer a `-short` flag to run a lighter version of tests.\n\nIt may be necessary to first run `CI=true ./tools/syz-env make descriptions` to\npre-build descriptions for the `sys/*` targets. It may be necessary for all\ntests that eventually use `prog.Target` or `targets.Target`.\n\n## Key Directories\n\n-   `syz-manager/`: Entry point for the main fuzzing manager.\n-   `executor/`: C++ source code for the test program executor.\n-   `pkg/`: Core Go libraries:\n    -   `pkg/ipc`: IPC mechanism between manager and executor.\n    -   `pkg/fuzzer`: Fuzzing logic.\n    -   `pkg/manager`: Manager logic library.\n-   `sys/`: System call descriptions (essential for the fuzzer to know how to call the kernel).\n    -   `sys/linux/`: Linux-specific descriptions (`.txt` and `.const`).\n-   `tools/`: Helper utilities (`syz-repro`, `syz-mutate`, etc.).\n-   `docs/`: Extensive documentation on setup, internals, and contribution.\n\n## Development Conventions\n\n-   **Commit Messages:** Strict formatting required.\n    -   Format: `dir/path: description` (e.g., `pkg/fuzzer: fix crash in minimization`).\n    -   No trailing dot in the summary.\n    -   The description after the colon MUST start with a lowercase letter.\n    -   Never add `TAG=` and `CONV=` tags to the commit/patch descriptions.\n-   **Testing:** New features must have tests. When writing test assertions, prefer using `require.Equal(t, tt.want, got)` from the `github.com/stretchr/testify/require` package instead of manual `if` comparisons or `if err != nil { t.Fatal(err) }`. Use raw string literals where they improve readability (e.g., when verifying multi-line text outputs).\n-   **Go Standard Library Utilities:** Prefer using functions from the standard `slices` and `maps` packages introduced in Go 1.21+ (e.g., `slices.Contains`, `slices.Clone`, `slices.DeleteFunc`, `maps.Keys`) instead of handwriting loops or custom utility functions for these operations.\n    -   *Exception:* Be mindful of performance. For example, do not replace a binary search with `slices.Contains` (which is linear $O(N)$) in performance-critical code.\n-   **Formatting:** Always run `make format` before committing.\n-   **Linting:** Always run the linter (`make lint` or `golangci-lint run ./...`) to fix all problems when a big patch is ready or structural changes are finalized.\n-   **Syscall Descriptions:** When modifying `sys/*/*.txt`, `make generate` must be run to update generated code.\n-   **Copyright:** When you add new .go files, make sure to add the copyright header to them (use other .go files for reference and update the year to the current one).\n\n## Guidelines\n\n-   `docs/review_guidelines.md`: Automated code review guidelines for Go, testing, architecture, and Syzkaller specifics.\n\n## Other GEMINI.md files\n\nThere exist other GEMINI.md files:\n- `sys/GEMINI.md` - consider it when you are asked to write/modify syzlang descriptions.\n- `syz-cluster/GEMINI.md` - consider it when working on the syz-cluster (patch fuzzing) functionality.\n- `pkg/aflow/GEMINI.md` - consider it when working on the aflow (agentic flow) functionality.\n"},"files":{"GEMINI.md":"# syzkaller - Context for Gemini\n\n## Project Overview\n`syzkaller` is an unsupervised, coverage-guided kernel fuzzer. It is a hybrid\nsystem consisting of a **Go-based manager** (running on a host) and a **C++\nexecutor** (running inside the target VM).\n\n-   **Primary Language:** Go (Manager, Tools), C++ (Executor).\n-   **Architecture:**\n    -   `syz-manager`: Orchestrates the fuzzing process, manages corpus, and monitors VMs.\n    -   `syz-executor`: Runs inside the VM, executes test programs via syscalls, and collects coverage.\n    -   `syz-ci`, `syz-hub`, `dashboard`: Infrastructure for continuous fuzzing and reporting.\n\n## Building and Testing\n\nPrefer to use the `syz-env` Docker container to build the compontents and run\ntests. There's a `./tools/syz-env` script that will start a container and run\nthe given command inside it.\n\nSome reference commands:\n* Build everything: `CI=true ./tools/syz-env make`.\n* Run a linter: `CI=true ./tools/syz-env make lint`.\n* Run a test: `CI=true ./tools/syz-env go test ./package -run TestName`.\n* Formatter: `CI=true ./tools/syz-env make format` (runs `gofmt`, `clang-format`, etc).\n\nNote the `CI=true` part - otherwise the commands may not run in your environment.\n\nWhen running tests (especially in `./prog` and `./pkg/csource`) prefer to run\nindividual tests you have affected, otherwise it may take a lot of time. Some\npackages also offer a `-short` flag to run a lighter version of tests.\n\nIt may be necessary to first run `CI=true ./tools/syz-env make descriptions` to\npre-build descriptions for the `sys/*` targets. It may be necessary for all\ntests that eventually use `prog.Target` or `targets.Target`.\n\n## Key Directories\n\n-   `syz-manager/`: Entry point for the main fuzzing manager.\n-   `executor/`: C++ source code for the test program executor.\n-   `pkg/`: Core Go libraries:\n    -   `pkg/ipc`: IPC mechanism between manager and executor.\n    -   `pkg/fuzzer`: Fuzzing logic.\n    -   `pkg/manager`: Manager logic library.\n-   `sys/`: System call descriptions (essential for the fuzzer to know how to call the kernel).\n    -   `sys/linux/`: Linux-specific descriptions (`.txt` and `.const`).\n-   `tools/`: Helper utilities (`syz-repro`, `syz-mutate`, etc.).\n-   `docs/`: Extensive documentation on setup, internals, and contribution.\n\n## Development Conventions\n\n-   **Commit Messages:** Strict formatting required.\n    -   Format: `dir/path: description` (e.g., `pkg/fuzzer: fix crash in minimization`).\n    -   No trailing dot in the summary.\n    -   The description after the colon MUST start with a lowercase letter.\n    -   Never add `TAG=` and `CONV=` tags to the commit/patch descriptions.\n-   **Testing:** New features must have tests. When writing test assertions, prefer using `require.Equal(t, tt.want, got)` from the `github.com/stretchr/testify/require` package instead of manual `if` comparisons or `if err != nil { t.Fatal(err) }`. Use raw string literals where they improve readability (e.g., when verifying multi-line text outputs).\n-   **Go Standard Library Utilities:** Prefer using functions from the standard `slices` and `maps` packages introduced in Go 1.21+ (e.g., `slices.Contains`, `slices.Clone`, `slices.DeleteFunc`, `maps.Keys`) instead of handwriting loops or custom utility functions for these operations.\n    -   *Exception:* Be mindful of performance. For example, do not replace a binary search with `slices.Contains` (which is linear $O(N)$) in performance-critical code.\n-   **Formatting:** Always run `make format` before committing.\n-   **Linting:** Always run the linter (`make lint` or `golangci-lint run ./...`) to fix all problems when a big patch is ready or structural changes are finalized.\n-   **Syscall Descriptions:** When modifying `sys/*/*.txt`, `make generate` must be run to update generated code.\n-   **Copyright:** When you add new .go files, make sure to add the copyright header to them (use other .go files for reference and update the year to the current one).\n\n## Guidelines\n\n-   `docs/review_guidelines.md`: Automated code review guidelines for Go, testing, architecture, and Syzkaller specifics.\n\n## Other GEMINI.md files\n\nThere exist other GEMINI.md files:\n- `sys/GEMINI.md` - consider it when you are asked to write/modify syzlang descriptions.\n- `syz-cluster/GEMINI.md` - consider it when working on the syz-cluster (patch fuzzing) functionality.\n- `pkg/aflow/GEMINI.md` - consider it when working on the aflow (agentic flow) functionality.\n"},"items":[{"name":"GEMINI.md","path":"GEMINI.md","title":"GEMINI.md","content":"# syzkaller - Context for Gemini\n\n## Project Overview\n`syzkaller` is an unsupervised, coverage-guided kernel fuzzer. It is a hybrid\nsystem consisting of a **Go-based manager** (running on a host) and a **C++\nexecutor** (running inside the target VM).\n\n-   **Primary Language:** Go (Manager, Tools), C++ (Executor).\n-   **Architecture:**\n    -   `syz-manager`: Orchestrates the fuzzing process, manages corpus, and monitors VMs.\n    -   `syz-executor`: Runs inside the VM, executes test programs via syscalls, and collects coverage.\n    -   `syz-ci`, `syz-hub`, `dashboard`: Infrastructure for continuous fuzzing and reporting.\n\n## Building and Testing\n\nPrefer to use the `syz-env` Docker container to build the compontents and run\ntests. There's a `./tools/syz-env` script that will start a container and run\nthe given command inside it.\n\nSome reference commands:\n* Build everything: `CI=true ./tools/syz-env make`.\n* Run a linter: `CI=true ./tools/syz-env make lint`.\n* Run a test: `CI=true ./tools/syz-env go test ./package -run TestName`.\n* Formatter: `CI=true ./tools/syz-env make format` (runs `gofmt`, `clang-format`, etc).\n\nNote the `CI=true` part - otherwise the commands may not run in your environment.\n\nWhen running tests (especially in `./prog` and `./pkg/csource`) prefer to run\nindividual tests you have affected, otherwise it may take a lot of time. Some\npackages also offer a `-short` flag to run a lighter version of tests.\n\nIt may be necessary to first run `CI=true ./tools/syz-env make descriptions` to\npre-build descriptions for the `sys/*` targets. It may be necessary for all\ntests that eventually use `prog.Target` or `targets.Target`.\n\n## Key Directories\n\n-   `syz-manager/`: Entry point for the main fuzzing manager.\n-   `executor/`: C++ source code for the test program executor.\n-   `pkg/`: Core Go libraries:\n    -   `pkg/ipc`: IPC mechanism between manager and executor.\n    -   `pkg/fuzzer`: Fuzzing logic.\n    -   `pkg/manager`: Manager logic library.\n-   `sys/`: System call descriptions (essential for the fuzzer to know how to call the kernel).\n    -   `sys/linux/`: Linux-specific descriptions (`.txt` and `.const`).\n-   `tools/`: Helper utilities (`syz-repro`, `syz-mutate`, etc.).\n-   `docs/`: Extensive documentation on setup, internals, and contribution.\n\n## Development Conventions\n\n-   **Commit Messages:** Strict formatting required.\n    -   Format: `dir/path: description` (e.g., `pkg/fuzzer: fix crash in minimization`).\n    -   No trailing dot in the summary.\n    -   The description after the colon MUST start with a lowercase letter.\n    -   Never add `TAG=` and `CONV=` tags to the commit/patch descriptions.\n-   **Testing:** New features must have tests. When writing test assertions, prefer using `require.Equal(t, tt.want, got)` from the `github.com/stretchr/testify/require` package instead of manual `if` comparisons or `if err != nil { t.Fatal(err) }`. Use raw string literals where they improve readability (e.g., when verifying multi-line text outputs).\n-   **Go Standard Library Utilities:** Prefer using functions from the standard `slices` and `maps` packages introduced in Go 1.21+ (e.g., `slices.Contains`, `slices.Clone`, `slices.DeleteFunc`, `maps.Keys`) instead of handwriting loops or custom utility functions for these operations.\n    -   *Exception:* Be mindful of performance. For example, do not replace a binary search with `slices.Contains` (which is linear $O(N)$) in performance-critical code.\n-   **Formatting:** Always run `make format` before committing.\n-   **Linting:** Always run the linter (`make lint` or `golangci-lint run ./...`) to fix all problems when a big patch is ready or structural changes are finalized.\n-   **Syscall Descriptions:** When modifying `sys/*/*.txt`, `make generate` must be run to update generated code.\n-   **Copyright:** When you add new .go files, make sure to add the copyright header to them (use other .go files for reference and update the year to the current one).\n\n## Guidelines\n\n-   `docs/review_guidelines.md`: Automated code review guidelines for Go, testing, architecture, and Syzkaller specifics.\n\n## Other GEMINI.md files\n\nThere exist other GEMINI.md files:\n- `sys/GEMINI.md` - consider it when you are asked to write/modify syzlang descriptions.\n- `syz-cluster/GEMINI.md` - consider it when working on the syz-cluster (patch fuzzing) functionality.\n- `pkg/aflow/GEMINI.md` - consider it when working on the aflow (agentic flow) functionality.\n","category":"root","tokens":1117}]}