Hello,
I am trying to experiment fuzzing fuchsia with syzkaller by following the documentation provided here: https://github.com/google/syzkaller/blob/master/docs/fuchsia/README.md.
I get the following output when trying to build a fuchsia image:
fx --dir "out/arm64" set core.arm64 --with-base "//bundles:tools" --with-base "//src/testing/fuzzing/syzkaller" --args=syzkaller_dir='"/home/behouba/Desktop/kos-fuzzing/syzkaller"'
WARNING: Please opt in or out of fx metrics collection.
You will receive this warning until an option is selected.
To check what data we collect, run `fx metrics`
To opt in or out, run `fx metrics <enable|disable>
ERROR at //build/go/go_library.gni:43:3 (//build/toolchain:host_x64): Assertion failed.
assert(defined(invoker.sources), "sources is required for go_library")
^-----
sources is required for go_library
See //src/testing/fuzzing/syzkaller/BUILD.gn:107:3: whence it was called.
go_library("syzkaller-go") {
^---------------------------
See //src/testing/fuzzing/syzkaller/BUILD.gn:86:5: which caused the file to be included.
":run-sysgen($host_toolchain)",
^-----------------------------
ERROR: error running gn gen: exit status 1
Can someone help please )
--
All posts must follow the Fuchsia Code of Conduct https://fuchsia.dev/fuchsia-src/CODE_OF_CONDUCT or may be removed.
---
You received this message because you are subscribed to the Google Groups "discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss+u...@fuchsia.dev.
To view this discussion on the web visit https://groups.google.com/a/fuchsia.dev/d/msgid/discuss/b85d5c70-0b71-4b5e-af19-c24a62b47110n%40fuchsia.dev.
To view this discussion on the web visit https://groups.google.com/a/fuchsia.dev/d/msgid/discuss/CAK0PkCFM7QjUrh_z13j_EE12ghC62yYs0RDVTaZhoNPsvw%3Dy-g%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/fuchsia.dev/d/msgid/discuss/c70e1150-be3e-4f26-aa56-9cca09787443n%40fuchsia.dev.
This is correct; a resourcing decision was made more than a year ago with the consequence that the increasing costs of syzkaller couldn't be maintained. The situation is starting to look a little better, and I'm optimistic we'll get back to system call fuzzing soon. In the meantime, the short term action is probably to make it clearer that syzkaller is deprecated and its replacement is not ready yet.AaronOn Mon, May 9, 2022 at 3:29 PM Chris Palmer <pal...@google.com> wrote:+Cameron Finucane and +Aaron Green and +Ange Albertini — in general, as I understand it, syzkaller is known to not work anymore. (Alas!) We know this is a problem and we are working on it, but the solution will probably be to have a new system call fuzzing framework; syzkaller was not working for us for a few reasons. Behouba, if you have ideas for what you'd like to see in a system call fuzzing framework, we'd love to hear them. :)
+Cameron Finucane and +Aaron Green and +Ange Albertini — in general, as I understand it, syzkaller is known to not work anymore. (Alas!) We know this is a problem and we are working on it, but the solution will probably be to have a new system call fuzzing framework; syzkaller was not working for us for a few reasons. Behouba, if you have ideas for what you'd like to see in a system call fuzzing framework, we'd love to hear them. :)
On Sun, May 8, 2022 at 3:43 PM Shai Barack <sha...@google.com> wrote:
why exactly did you end up abandoning syzkaller?
I'm curious, why exactly did you end up abandoning syzkaller? I know you mentioned maintenance costs, but most projects seem to roll with it just fine.
guided as we wanted. For this reason, we decided to focus what limited resources we had on other taks first, e.g. implementing kcov for Zircon.
Hope that helps,Aaron