Separate kernel and syzkaller build failures.
Fix logic to understand when a build is fixed:
look if kernel/syzkaller commit changes to understand
if it's a new good build or re-upload of an old build.
Fixes#1014
Trusty is a set of software components supporting
a Trusted Execution Environment (TEE) on mobile devices.
https://source.android.com/security/trusty
Add syscall descriptions and some boilerplate.
Currently target binaries contain support for all OS/arch combinations.
However, obviously a fuchsia target binary won't test windows.
For target binaries we need support only for a single target
(with the exception of 386/arm target in amd64/arm64 binaries).
So compile in only _the_ target into target binaries.
This reduces akaros/amd64 fuzzer binary from 33 to 7 MB
and execprog from 28 to 2 MB.
* Lots of changes to sys/netbsd:
- Removed a few syscalls that did not have proper constants defined.
- Autogenerated *.const files.
- Removed a few types like uid and gid, that were not available.
- Ran make generate
* Few changes for NetBSD support:
- Added sys/netbsd/init.go
- Added netbsd to sys/sys.go
* Fix order in sys/sys.go
* Update documentation for NetBSD
This breaks circular dependency between:
sysgen -> sys/linux -> sys -> sysgen
With this circular dependency it is very difficult to
update format of generated descriptions because sysgen does not build.
We used to generate them only because manager had no idea
what arch it is testing. So syscalls numbers had to match
between all arches.
This is not needed anymore.
Also don't generate unreferenced structs/resources.
Info about targets (like C arch/CFLAGS) is required in multiple places:
extract.sh
syz-extract
syz-sysgen
csource
vm/qemu
...
Consolidate it in one place and use that in syz-sysgen.
This splits generation process into two phases:
1. Extract values of constants from linux kernel sources.
2. Generate Go code.
Constant values are checked in.
The advantage is that the second phase is now completely independent
from linux source files, kernel version, presence of headers for
particular drivers, etc. This allows to change what Go code we generate
any time without access to all kernel headers (which in future won't be
limited to only upstream headers).
Constant extraction process does require proper kernel sources,
but this can be done only once by the person who added the driver
and has access to the required sources. Then the constant values
are checked in for others to use.
Consant extraction process is per-file/per-arch. That is,
if I am adding a driver that is not present upstream and that
works only on a single arch, I will check in constants only for
that driver and for that arch.
This solves several problems:
- host usually have outdates headers, so previously we need to define missing consts
- host may not have some headers at all
- generation depends on linux distribution and version
- some of the consts cannot be defined at all (e.g. ioctls that use struct arguments)
