Change all 'filename' to 'ptr[in, filename]' and don't imply pointer indirection for filename type.
This is necessary because in some bases we want to embed filename directly into a struct (e.g. unix sock addr).
Similar change was already done for string type for similar reasons. Generally, we want to imply as less as possible.
NOTE: IF YOU HAVE PRIVATE DESCRIPTIONS, YOU NEED TO DO THE SAME REPLACEMENT.
1. Basic support for arm64 kvm testing.
2. Fix compiler warnings in x86 kvm code.
3. Test all pseudo syz calls in csource.
4. Fix handling of real code in x86.
Add new pseudo syscall syz_kvm_setup_cpu that setups VCPU into
interesting states for execution. KVM is too difficult to setup otherwise.
Lots of improvements possible, but this is a starting point.
IP addresses like 192.168.0.1/192.168.1.1 are often used for routing between VM and the host.
Offset our IP addresses to start from 192.168.218.0 to reduce potential conflicts.
Go compiler does not seem to like long generated functions.
This change reduces compilation time of sys_arch.go,
reduces compiler memory consumption and fixes compiler crash on arm64.
This allows to write:
string[salg_type, 14]
which will give a string buffer of size 14 regardless of actual string size.
Convert salg_type/salg_name to this.
Allow to define string flags in txt descriptions. E.g.:
filesystem = "ext2", "ext3", "ext4"
and then use it in string type:
ptr[in, string[filesystem]]
Currently we store most types by value in sys.Type.
This is somewhat counter-intuitive for C++ programmers,
because one can't easily update the type object.
Store pointers to type objects for all types.
It also makes it easier to update types, e.g. adding paddings.
Add sys/test.txt file with description of syscalls for tests.
These descriptions can be used to ensure that we can parse everything we clain we can parse.
Use these descriptions to write several tests for exec serialization
(one test shows that alignment handling is currently incorrect).
These test descriptions can also be used to write e.g. mutation tests.
Update #78
Currently to add a new resource one needs to modify multiple source files,
which complicates descirption of new system calls.
Move resource descriptions from source code to text desciptions.
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 commit supports inclusive ranged int, like foo int32[-10~10], which will
generate random integer between -10 and 10. In future we will support more than
one range, like int32[0, -5~10, 50, 100~200]
When regenerating system call tables, cope with a local kernel tree where
the kernel has been built into a separate directory (with `make O=...`) rather
than inline.
So:
- LINUX makefile var / -linux command line option give location of source tree
- LINUXBLD makefile var / -linuxbld command line option gives location of
built kernel
