You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We maintain a lossless compression codec with two independent GPU backends (CUDA and Vulkan) that produce byte-identical output and decode each other's frames. We fuzz it locally at around 10M differential iterations a night, using each backend as the other's oracle.
Two questions about whether any of this fits OSS-Fuzz.
1. Is a project like this worth submitting for its host-side surface alone?
The GPU kernels are not currently instrumentable by libFuzzer, but a meaningful part of the attack surface isn't kernel code at all. Our frame header parser, transform-section parser and chunk-table parser are plain CPU code over untrusted bytes, with no GPU dependency and we already fuzz them with Zig's built-in coverage-guided fuzzer. We have already fixed several integrity bugs this month that lived in host-side code.
Is a GPU-centric project with a CPU-instrumentable parser surface something you'd consider, or does the GPU dependency in the rest of the codebase make it a poor fit regardless?
2. Are GPU-capable runners something OSS-Fuzz would ever consider?
We understand the current builders are x86_64/i386 and that coverage instrumentation and the sanitizers both target host code, so GPU machines alone wouldn't let libFuzzer see device code. We're not asking for kernel instrumentation (compute-sanitizer and Vulkan GPU-AV cover that and we run them ourselves).
The narrower question is: on a GPU-equipped runner, host-side coverage guidance would still apply to the driver and dispatch code that calls into the GPU, which is where our bugs have actually been. Is that combination something you've considered, or is it out of scope on cost and determinism grounds? A clear "not planned" is a useful answer. It tells projects like ours to stop looking.
3. Is device-side coverage instrumentation tracked anywhere?
We understand this isn't OSS-Fuzz's layer - SanitizerCoverage would need to emit through NVPTX/SPIR-V, with a device-side runtime to accumulate counters and a way to merge them per execution. Research fuzzers like cuFuzz exist because of that gap. Is anyone upstream tracking it, or is GPU coverage guidance simply out of scope for the foreseeable future? A pointer to the right issue or project would be enough.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
We maintain a lossless compression codec with two independent GPU backends (CUDA and Vulkan) that produce byte-identical output and decode each other's frames. We fuzz it locally at around 10M differential iterations a night, using each backend as the other's oracle.
Two questions about whether any of this fits OSS-Fuzz.
1. Is a project like this worth submitting for its host-side surface alone?
The GPU kernels are not currently instrumentable by libFuzzer, but a meaningful part of the attack surface isn't kernel code at all. Our frame header parser, transform-section parser and chunk-table parser are plain CPU code over untrusted bytes, with no GPU dependency and we already fuzz them with Zig's built-in coverage-guided fuzzer. We have already fixed several integrity bugs this month that lived in host-side code.
Is a GPU-centric project with a CPU-instrumentable parser surface something you'd consider, or does the GPU dependency in the rest of the codebase make it a poor fit regardless?
2. Are GPU-capable runners something OSS-Fuzz would ever consider?
We understand the current builders are x86_64/i386 and that coverage instrumentation and the sanitizers both target host code, so GPU machines alone wouldn't let libFuzzer see device code. We're not asking for kernel instrumentation (compute-sanitizer and Vulkan GPU-AV cover that and we run them ourselves).
The narrower question is: on a GPU-equipped runner, host-side coverage guidance would still apply to the driver and dispatch code that calls into the GPU, which is where our bugs have actually been. Is that combination something you've considered, or is it out of scope on cost and determinism grounds? A clear "not planned" is a useful answer. It tells projects like ours to stop looking.
3. Is device-side coverage instrumentation tracked anywhere?
We understand this isn't OSS-Fuzz's layer - SanitizerCoverage would need to emit through NVPTX/SPIR-V, with a device-side runtime to accumulate counters and a way to merge them per execution. Research fuzzers like cuFuzz exist because of that gap. Is anyone upstream tracking it, or is GPU coverage guidance simply out of scope for the foreseeable future? A pointer to the right issue or project would be enough.
Happy to share the repo if useful.
All reactions