We now check for manager-fuzzer-executor commit mismatch (see Manager.Check).
But in some cases commit mismatch is not detected gracefully, and instead
leads to panics in fuzzer. Namely, when -enabled_syscalls fuzzer flag includes
large syscalls numbers, so large that they are no present at all in the an old
revision that fuzzer uses, in such case fuzzer panics.
Notify manager about invalid calls instead.
Fixes#464
Currently one needs to switch between config_stub.go and prod
config back and forth on every deployment. This is very
inconvinient. Rework config, so that switching is not necessary.
bug.LastTime is updated on every crash, even if we don't save it.
As the result we did not save recent crashes for popular bugs at all.
Fix this by introducing bug.LastSavedCrash.
We see some crashes that suggest corruption of the syscall number:
invalid command number 1296 (errno 11)
invalid command number 107 (errno 110)
Make the table and the number constant to prevent corruption.
This will harden non-root programs from kernel side, but not
root-only ones. Helps also to increase coverage a bit since
syzkaller generates programs for both cases.
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
We currently have native cross-compilation logic duplicated
in Makefile and in sys/targets. Some pieces are missed in one
place, some are in another. Only pkg/csource knows how to check
for -static support.
Move all CC/CFLAGS logic to sys/targets and pull results in Makefile.
This should make Makefile work on distros that have broken x86_64-linux-gnu-gcc,
now we will use just gcc. And this removes the need to define NOSTATIC,
as it's always auto-detected.
This also paves the way for making pkg/csource work on OSes other than Linux.
The id field in the v4l2_event_subscription structure
currently described as: id len[type, int32].
But all the documentation states is:
"id - ID of the event source. If there is no ID associated
with the event source, then set this to 0. Whether or not
an event needs an ID depends on the event type."
So, the documentation clearly states that:
1. id - is the source of an event
2. type - is the type of an event
3. for some types of events there is no source and id can be 0
According to this 'id int32' is more accurate description of
the field.
