We test in a new network namespace, which does not have any
devices set up (even lo). Create/up as many devices as possible.
Give them some addresses and use these addresses in descriptions.
Netlink descriptions contain tons of code duplication,
and need much more for proper descriptions. Introduce
type templates to simplify writing such descriptions
and remove code duplication.
Note: type templates are experimental, have poor error handling
and are subject to change.
Type templates can be declared as follows:
```
type buffer[DIR] ptr[DIR, array[int8]]
type fileoff[BASE] BASE
type nlattr[TYPE, PAYLOAD] {
nla_len len[parent, int16]
nla_type const[TYPE, int16]
payload PAYLOAD
} [align_4]
```
and later used as follows:
```
syscall(a buffer[in], b fileoff[int64], c ptr[in, nlattr[FOO, int32]])
```
Arm was broken on upstream kernel for some time
due to some assembler error. Now it seems to be fixed,
so regenerate consts.
Also fix small issues in new netlink descriptions.
Don't print object size (can change from kernel to kernel
and from config to config).
Fix function extraction regexp (must be non-eager).
Account for MSECS_MIN_AGE.
Ignore some known false positives.
open is not present on arm64, only openat.
accept is not present on 386, only accept4.
Duplicate all open/accept specializations with
corresponding openat/accept4 specializations
to enable testing on 386/arm64.
Few managers recently crashed with:
panic: syscall mknod$loop: per proc arg 'proc' has bad value '4294967295'
panic: sync: unlock of unlocked mutex
goroutine 35438 [running]:
sync.(*Mutex).Unlock(0xc42166e0c8)
sync/mutex.go:184 +0xc1
panic(0xb98980, 0xc448971aa0)
runtime/panic.go:491 +0x283
main.(*Manager).Connect(0xc42166e000, 0xc42056d060, 0xc42038f000, 0x0, 0x0)
syz-manager/manager.go:868 +0x11cc
And a similar issue was reported on mailing list.
It's unclear where these bogus programs come from.
It seems that hub was somehow involved here.
4294967295 is (uint32)-1 which is trucated special
value for proc types.
The test did not uncover any bugs, bug since I wrote it
and it looks like a useful test, let's commit it anyway.
This adds builtin:
type bool8 int8[0:1]
type bool16 int16[0:1]
type bool32 int32[0:1]
type bool64 int64[0:1]
type boolptr intptr[0:1]
We used to use just int's for bools.
But bool types provide several advantages:
- make true/false probability equal
- improve description expressiveness
- reduce search space (we will take advantage of this later)
Complex types that are often repeated can be given short type aliases using the
following syntax:
```
type identifier underlying_type
```
For example:
```
type signalno int32[0:65]
type net_port proc[20000, 4, int16be]
```
Then, type alias can be used instead of the underlying type in any contexts.
Underlying type needs to be described as if it's a struct field, that is,
with the base type if it's required. However, type alias can be used as syscall
arguments as well. Underlying types are currently restricted to integer types,
`ptr`, `ptr64`, `const`, `flags` and `proc` types.
On another machine both clang and gcc produce:
test.c:163:32: error: invalid suffix "+procid" on integer constant
*(uint32_t*)0x20001004 = 0x25dfdbfe+procid*4;
Not sure why this wasn't caught on buildbot.
