[Discussion] Debian package for syzkaller – worth upstreaming?

[Yunseong Kim]

Hi,

I’m currently working on creating a Debian package for syzkaller[1]. I’m going through code review and making updates.

Do you think it would make sense to submit the packaging as a PR to the syzkaller project? I’d like to hear your thoughts.

In particular, I’m very interested in running fuzzing workloads on bare-metal machines using debug kernels and isolated environments. While Debian doesn’t currently provide a debug kernel as a default package, I’m exploring ways to add one[2], as it could be quite valuable for syzkaller users who want deeper kernel instrumentation and debugging capabilities.

Thank you,

Yunseong

[1] [PATCH] debian: packaging syzkaller
: https://lists.debian.org/debian-mentors/2024/08/msg00341.html

[2] Re: [RFC] Proposal for Adding a Dedicated Debug Kernel Package to Debian(follow-up from DebCamp on DebConf25)
 https://lists.debian.org/debian-kernel/2025/08/msg00003.html

[Dmitry Vyukov]

Hi Yunseong,

Great to see more interest from the Debian community!

What exactly do you want to submit to the syzkaller project? Package
descriptions and kernel configs probably belong to a distro, right?

Btw we've considered fuzzing the Debian kernel on syzbot. There was
some discussion on debian mailing lists IIRC, but can't find it now.
We did not get a clear signal with respect to interest from the Debian
community, so this did not setup it on syzbot. But we can reconsider.

[Yunseong Kim]

Hi Dmitry,

Thanks for the insights and feedback!

On 8/11/25 9:09 오후, Dmitry Vyukov wrote:
> On Fri, 8 Aug 2025 at 02:39, Yunseong Kim <y...@kzalloc.com> wrote:
>>
>> Hi,
>>
>> I’m currently working on creating a Debian package for syzkaller[1]. I’m going through code review and making updates.
>>
>> Do you think it would make sense to submit the packaging as a PR to the syzkaller project? I’d like to hear your thoughts.
>>
>> In particular, I’m very interested in running fuzzing workloads on bare-metal machines using debug kernels and isolated environments. While Debian doesn’t currently provide a debug kernel as a default package, I’m exploring ways to add one[2], as it could be quite valuable for syzkaller users who want deeper kernel instrumentation and debugging capabilities.
>>
>>
>> Thank you,
>>
>> Yunseong
>>
>>
>> [1] [PATCH] debian: packaging syzkaller
>> : https://lists.debian.org/debian-mentors/2024/08/msg00341.html
>> [2] Re: [RFC] Proposal for Adding a Dedicated Debug Kernel Package to Debian(follow-up from DebCamp on DebConf25)
>> https://lists.debian.org/debian-kernel/2025/08/msg00003.html
>
> Hi Yunseong,
>
> Great to see more interest from the Debian community!

I’ve learned a great deal about the linux kernel through syzkaller,
and it’s an honor to be able to contribute.

> What exactly do you want to submit to the syzkaller project? Package
> descriptions and kernel configs probably belong to a distro, right?

I’m working on a debian script to install syzkaller as a .deb package[1],
with the long-term goal of enabling .deb builds using syz-build — similar
to how the Linux kernel supports "make deb-pkg" — to improve accessibility
across architectures.

I thought it would be great if interested Debian kernel developers could easily
install syzkaller via apt install syzkaller and run fuzzing on their own
development boards, laptops, or isolated machines to test their products.

Since Debian doesn’t have a debug kernel yet, I’m planning to reference syzbot’s
config and Fedora’s debug config a lot. I’ll discuss this more later, but it
definitely needs thorough discussion. The most important thing is to enable
"KCOV", which is missing even in Fedora and Red Hat debug kernels.

> Btw we've considered fuzzing the Debian kernel on syzbot. There was
> some discussion on debian mailing lists IIRC, but can't find it now.
> We did not get a clear signal with respect to interest from the Debian
> community, so this did not setup it on syzbot. But we can reconsider.

I’ve read the past thread [2] in detail, and it was very helpful.

During DebConf25, I suggested to Ben from the Debian kernel team the idea of a
dedicated debug kernel package While technically straightforward, it will need
consensus within the Debian kernel team. The concept, inspired by syzbot, may be
challenging to realize in such fine-grained form, but given Debian’s precedent
with RT kernel packages[3], I believe it’s worth pursuing.

I’ll bring it up again in the Debian kernel team channel as discussed.


Thanks!

Best regards,
Yunseong

[1] debian: packaging syzkaller
* https://lists.debian.org/debian-mentors/2024/08/msg00341.html

[2] debian: packaging syzkaller
* Re: Debian kernel testing on syzbot (https://lists.debian.org/debian-kernel/2023/07/msg00073.html) *Dmitry Vyukov
* Re: Debian kernel testing on syzbot (https://lists.debian.org/debian-kernel/2023/07/msg00074.html) *Bo YU
* Re: Debian kernel testing on syzbot (https://lists.debian.org/debian-kernel/2023/07/msg00085.html) *Dmitry Vyukov
* Re: Debian kernel testing on syzbot (https://lists.debian.org/debian-kernel/2023/07/msg00108.html) *Bo YU
* Re: Debian kernel testing on syzbot (https://lists.debian.org/debian-kernel/2023/07/msg00224.html) *Ben Hutchings
* Re: Debian kernel testing on syzbot (https://lists.debian.org/debian-kernel/2023/07/msg00243.html) *Salvatore Bonaccorso
* Re: Debian kernel testing on syzbot (https://lists.debian.org/debian-kernel/2023/07/msg00255.html) *Dmitry Vyukov

[3] Debian RT Kernel Config and trixie kernel
* https://salsa.debian.org/kernel-team/linux/-/blob/debian/6.16-1_exp1/debian/config/config.rt
* https://packages.debian.org/trixie/linux-image-6.12.31-rt-amd64

[Dmitry Vyukov]

I am not sure I follow high-level pictures. Are these several
independent things?
What will happen with deb packages built by syz-build? The rest of
syzkaller can't use deb files.

> Since Debian doesn’t have a debug kernel yet, I’m planning to reference syzbot’s
> config and Fedora’s debug config a lot. I’ll discuss this more later, but it
> definitely needs thorough discussion. The most important thing is to enable
> "KCOV", which is missing even in Fedora and Red Hat debug kernels.
>
> > Btw we've considered fuzzing the Debian kernel on syzbot. There was
> > some discussion on debian mailing lists IIRC, but can't find it now.
> > We did not get a clear signal with respect to interest from the Debian
> > community, so this did not setup it on syzbot. But we can reconsider.
>
> I’ve read the past thread [2] in detail, and it was very helpful.
>
> During DebConf25, I suggested to Ben from the Debian kernel team the idea of a
> dedicated debug kernel package While technically straightforward, it will need
> consensus within the Debian kernel team. The concept, inspired by syzbot, may be
> challenging to realize in such fine-grained form, but given Debian’s precedent
> with RT kernel packages[3], I believe it’s worth pursuing.

There is no need to re-implement syzbot. The idea was to setup Debian
testing on the syzbot.

[Yunseong Kim]

Hi Dmitry,

Thank you for the follow-up. I apologize for the confusion in my previous email.

I’m sorry — I mistakenly wrote 'syz-build' when I actually meant 'syz-env'.
I got them mixed up. It seems my analogy to the Linux kernel's
'make deb-pkg' caused a key misunderstanding regarding my goals.


Let me clarify the initiatives.

1. Clarification on Debian Packaging for syzkaller

It appears there was a misunderstanding about the target of the packaging.

I realize now why my previous explanation was unclear. I was not referring to
packaging the kernel under test into a .deb. You are correct that syzkaller
cannot use kernel .deb files for fuzzing.

My proposal was about packaging the syzkaller tools themselves, the Go binaries
in bin/, such as syz-manager, syz-fuzzer, etc.

The analogy to make deb-pkg was meant to suggest a mechanism within the
syzkaller repository similar to how the Linux kernel handles its own packaging:

| $ cd syzkaller
|
| # builds binaries in bin/
| $ make
|
| # New step: uses scripts in debian/ to package the binaries from bin/
| make deb-pkg # like Linux kernel's 'make deb-pkg'
|
| $ ls *.deb
| syzkaller(build-version-name-with-commit).deb

My initial question was whether contributing these debian/ packaging scripts
upstream would be acceptable. However, I agree with your assessment that
"Package descriptions... probably belong to a distro." This effort is honestly
a much lower priority compared to the discussions around syzbot integration.

I can proceed with managing these scripts downstream in Debian salsa syzkaller
repository. Further work is needed following the code reviews by Debian
community members. The work I performed last year can be found at the following:

Link: https://salsa.debian.org/ysk/syzkaller/-/tree/debian/debian

>> Since Debian doesn’t have a debug kernel yet, I’m planning to reference syzbot’s
>> config and Fedora’s debug config a lot. I’ll discuss this more later, but it
>> definitely needs thorough discussion. The most important thing is to enable
>> "KCOV", which is missing even in Fedora and Red Hat debug kernels.
>>
>>> Btw we've considered fuzzing the Debian kernel on syzbot. There was
>>> some discussion on debian mailing lists IIRC, but can't find it now.
>>> We did not get a clear signal with respect to interest from the Debian
>>> community, so this did not setup it on syzbot. But we can reconsider.
>>
>> I’ve read the past thread [2] in detail, and it was very helpful.
>>
>> During DebConf25, I suggested to Ben from the Debian kernel team the idea of a
>> dedicated debug kernel package While technically straightforward, it will need
>> consensus within the Debian kernel team. The concept, inspired by syzbot, may be
>> challenging to realize in such fine-grained form, but given Debian’s precedent
>> with RT kernel packages[3], I believe it’s worth pursuing.
>
> There is no need to re-implement syzbot. The idea was to setup Debian
> testing on the syzbot.

2. Debian Debug Kernel and syzbot Integration

Yes, exactly. I made this confusing. I completely agree, and my focus remains
on providing the necessary foundation (a debug kernel) to enable effective
testing of Debian on the existing syzbot infrastructure.

On that note, I'm happy to share a brief update: the Debian Kernel Team
understands the necessity of this effort, and we are actively discussing the
best approach to create and maintain this debug kernel package. It's fortunate
that there's interest and collaboration on this front.

I have been greatly benefiting from syzkaller, and I plan to keep proposing
this to the Debian community. I also intend to bring it up at the next meeting.

>> I’ll bring it up again in the Debian kernel team channel as discussed.
>>
>>
>> Thanks!
>>
>> Best regards,
>> Yunseong
>>
>> [1] debian: packaging syzkaller
>> * https://lists.debian.org/debian-mentors/2024/08/msg00341.html
>>

>> [2] Debian kernel testing on syzbot

>> * Re: Debian kernel testing on syzbot (https://lists.debian.org/debian-kernel/2023/07/msg00073.html) *Dmitry Vyukov
>> * Re: Debian kernel testing on syzbot (https://lists.debian.org/debian-kernel/2023/07/msg00074.html) *Bo YU
>> * Re: Debian kernel testing on syzbot (https://lists.debian.org/debian-kernel/2023/07/msg00085.html) *Dmitry Vyukov
>> * Re: Debian kernel testing on syzbot (https://lists.debian.org/debian-kernel/2023/07/msg00108.html) *Bo YU
>> * Re: Debian kernel testing on syzbot (https://lists.debian.org/debian-kernel/2023/07/msg00224.html) *Ben Hutchings
>> * Re: Debian kernel testing on syzbot (https://lists.debian.org/debian-kernel/2023/07/msg00243.html) *Salvatore Bonaccorso
>> * Re: Debian kernel testing on syzbot (https://lists.debian.org/debian-kernel/2023/07/msg00255.html) *Dmitry Vyukov
>>

>> [3] Debian RT Kernel Config and trixie RT kernel

>> * https://salsa.debian.org/kernel-team/linux/-/blob/debian/6.16-1_exp1/debian/config/config.rt
>> * https://packages.debian.org/trixie/linux-image-6.12.31-rt-amd64

Thank you!

Yunseong

[Dmitry Vyukov]

I see. This makes sense now.
We could add the files to the syzkaller upstream.
If it's mostly Makefile changes and the changes are relatively large,
then it's probably better to add them to a separate sub-makefile. If
it's a shell script, then we could add it to tools/.

You could also a separate CI step that will ensure that the package at
least builds successfully (not sure if we can easily do more testing).
The CI steps are here:
https://github.com/google/syzkaller/blob/master/.github/workflows/ci.yml