IntelLabs / IntelLabs/kAFL

[Question/Discussion] Strategy for Fuzzing with VFIO Device Passthrough (e.g., GPU) and Snapshot Conflict

Open
#332 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
Makefile
Stars
814
Forks
109
PR merge metrics
No merged PRs in 30d

Description

Hello kAFL/Nyx team,

First of all, thank you for developing and maintaining this powerful fuzzing framework.

I am currently working on setting up a fuzzing environment for an NVIDIA GPU. My approach requires passing the GPU directly to the QEMU guest VM using VFIO device passthrough.

During my setup, I've encountered what appears to be a fundamental conflict between VFIO and Nyx's core snapshotting feature. My understanding is that the complex state of a physical device like a GPU cannot be reliably saved and restored by Nyx's memory-centric snapshot engine, which prevents the fuzzer from operating correctly with a passthrough device.

To move forward, I have managed to get the fuzzer running by modifying the QEMU source code to disable the snapshot functionality (DISABLE_SNAPSHOT: 1). However, this workaround has a critical side effect: many of kAFL's essential features, which are tightly coupled with the snapshot engine, become non-functional.

Most importantly, the Intel PT-based coverage feedback mechanism seems to be broken. The trace decoder relies on reading from the memory snapshot to reconstruct the execution path. Without snapshots, the fuzzer essentially runs "blind," without any coverage guidance.

I recognize that the snapshot feature is absolutely crucial for achieving high fuzzing throughput, so simply disabling it is not a viable long-term solution.

I would like to ask the developers and the community for your insights on this matter:

1.Is there a recommended or existing approach for fuzzing targets that require VFIO passthrough?

2.Have you considered, or are there any plans to support, a "snapshot-less" mode or perhaps a "partial snapshot" mode (e.g., snapshotting only RAM and not MMIO regions) that could be compatible with VFIO?

3.Are there any alternative strategies you might suggest for tackling this kind of hardware-in-the-loop target?

I am willing to help test or contribute to a potential solution. Any guidance or suggestions would be greatly appreciated.

Thank you for your time and consideration.

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.