| Commit message (Collapse) | Author | Age | Files | Lines |
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Syscall attributes are extended with a fsck command field which lets
file system mount definitions specify a fsck-like command to run. This
is required because all file systems have a custom fsck command
invokation style.
When uploading a compressed image asset to the dashboard, syz-manager
also runs the fsck command and logs its output over the dashapi.
The dashboard logs these fsck logs into the database.
This has been requested by fs maintainer Ted Tso who would like to
quickly understand whether a filesystem is corrupted or not before
looking at a reproducer in more details. Ultimately, this could be used
as an early triage sign to determine whether a bug is obviously
critical.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The expression may either include integers/consts or reference other
fields in the structure via value[field1:field2:field3].
The fields on this path must all belong to structures and must not have
any if conditions themselves.
For unions, mandate that the last field has no conditions (it will be
the default one).
For structs, convert conditional fields into fields of a union type of
the following form:
anonymous_union [
value T (if[expression])
void void
]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit adds the requirement that nested flags must be at the end of
the list of values. For example,
flags1 = 1, 2, 3, 4, flags2
flags2 cannot be moved to another position in the list. The goal is to
simplify parsing of the list by humans.
Enforcing that the nested flags be at the end (vs. the beginning) makes
things a bit easier for the parser. If we enforced that they should be
at the beginning, then the parser would need to look further forward to
determine if a flags definition is an integer flags or a string flags.
flags1 = flags2, flags3, flags4, 5, 6
In this example, the parser would need to look to the 4th value in the
list to tell that it's an integer flags.
Suggested-by: Aleksandr Nogikh <nogikh@google.com>
Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
|
| |
|
|
|
|
|
|
|
| |
This commit adds support for flags definitions such as:
flags1 = "string1", "string2"
flags2 = flags1, "string3"
Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
|
| |
|
|
|
|
|
|
| |
To detect those circular dependencies, we simply keep track of which
flags we already visited when flattening the flags definition.
Suggested-by: Aleksandr Nogikh <nogikh@google.com>
Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit adds support for flags definitions such as:
flags1 = VAL1, VAL2
flags2 = flags1, VAL3
This is achieved by flattening nested flag definitions as part of the
compilation. That is, nested flags are compiled into their fully
unreferenced/unnested form.
This flattening cannot be achieved in a single pass over the flags
because we don't have a guarantee that we will encounter the subflags
(ex. flags1 above) before their superflags (ex. flags2 above). Instead,
in a first pass, we need to build an indexing of flags that we can use
to flatten superflags in a second pass.
Thankfully, this indexing is already computed in the form of
comp.intFlags. Thus, we only need to implement the second pass, done
with function compiler.flattenFlags().
This second pass walks the flag definitions recursively in an attemp to
fully flatten them. It errors out if a flag definition has more than 5
levels of nested definitions.
Being able to error in that way requires a bit of care in how we flatten
the flags. Consider the following example where flags1 to flags5 have
less than 5 leves of nesting, whereas flags6 should cause an error.
flags6 = VAL6, flags5
flags5 = VAL5, flags6
...
flags1 = VAL1
If we were to flatten the flag definitions in place, then we might walk
into flags5 first and fully flatten it. As a result, when we would walk
into flags6, we would detect a single level of nesting and wouldn't
error out. To avoid that, we work on the original set of nested flags
and copy the flattened flags over only once we're done with all flags.
Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
|
| |
|
|
|
|
|
| |
This commit adds error cases that weren't covered before. They were
identified by looking at the coverage numbers for pkg/compiler.
Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit adds support for the following syntax:
int8[constant]
as an equivalent to:
const[constant, int8]
The goal is to have a unified const/flags definition that we can use in
templates. For example:
type template[CLASS, ...] {
class int8:3[CLASS]
// ...
}
type singleClassType template[SINGLE_CONST]
type subClassType template[abc_class_flags]
In this example, the CLASS template field can be either a constant or a
flag. This is especially useful when defining both a generic instance of
the template as well as specialized instances (ex. bpf_alu_ops and
bpf_add_op).
Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit adds support for the following syntax:
int_flags = 1, 5, 8, 9
int32[int_flags]
which is equivalent to:
int_flags = 1, 5, 8, 9
flags[int_flags, int32]
The second int type argument, align, is not allowed if the first
argument is a flag. The compiler will also error if the first argument
appears to be a flag (is ident and has no colon), but can't be found in
the map of flags.
Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Type args can currently have only one type of kindInt, kindIdent,
kindString, or kindAny. The descriptions are checked against expected
type arg kinds, with kindAny meaning that anything is allowed (often
restricted with custom checks).
Concretely, it means that in a description as follows, arg1 and arg2
can each take a single kind of values.
type[arg1, arg2]
This is limiting if we want arg1 to be able to take both an int or
flags. We thus need type args to support having mixed kinds. This
commit achieves this by turning the kind constants into bit flags.
This will be useful in a subsequent commit, but we can also already use
it for one existing type arg, the first of string types:
string[literal_or_flags, size]
literal_or_flags changes from kindAny to kindIdent|kindString and we can
remove the custom check that used to enforce this.
Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
We had a problem -- using inout ANYUNION leads to syzkaller generating
copyout instructions for fmt[X, resource] types.
Add a validation rule to detect this during tests.
Fix this by supporting (in) for union fields. Previously, all union
field direction attributes were banned as they were making things more
complicated.
The (in) attribute is definitely safe and allows for more flexibility.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
builtin
Create the `BufferCompressed` kind of `BufferType`, which will be used
to represent compressed data. Create the corresponding `compressed_image`
syzlang builtin, which is backed by `BufferCompressed`. For now, no
syscalls use this feature - this will be introduced in future commits.
We have to be careful to decompress the data before mutating, and
re-compress before storing. We make sure that any deserialised
`BufferCompressed` data is valid too.
`BufferCompressed` arguments are mutated using a generic heatmap. In
future, we could add variants of `BufferCompressed` or populate the
`BufferType` sub-kind, using it to choose different kinds of heatmap for
different uncompressed data formats.
Various operations on compressed data must be forbidden, so we check for
`BufferCompressed` in key places. We also have to ensure `compressed_image`
can only be used in syscalls that are marked `no_{generate,minimize}`.
Therefore, we add a generic compiler check which allows type
descriptions to require attributes on the syscalls which use them.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We have a bunch of hacks in syz-extract, syz-sysgen and syz-check
with respect to description files unsupported on some arches,
or that must not be part of make extract.
Add 2 meta attribtues to files:
meta noextract
Tells `make extract` to not extract constants for this file.
Though, `syz-extract` can still be invoked manually on this file.
meta arches["arch1", "arch2"]
Restricts this file only to the given set of architectures.
`make extract` and ``make generate` will not use it on other architectures.
Later we can potentially use meta attributes to specify git tree/commit
that must be used for extraction. Maybe something else.
Fixes #2754
|
| |
|
|
|
|
| |
Direction attributes on unions work in a confusing way and don't do
what users may think they do. Now we have out_overlay attribute
for structs that allows to have overlapping input and output fields.
|
| | |
|
| |
|
|
|
|
|
|
| |
It's a somewhat common mistake to write comments instead of directives:
#include <foo>
#define FOO BAR
because that's how it's done in C.
Warn about such cases.
|
| |
|
|
| |
Add 2 more tests for recursive templates.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Fix a bug found by OSS-Fuzz:
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=17240
We handled the case of infinite recursion in templates
but only if the full type name matches precisely (A -> B -> A).
In this case the name constantly changes due to different
template arguments. Per se this is a not an error
(and we have real cases that use this, e.g. when an nlattr_t
contains nested nlattr_t's), but it's an error if it recurses
infinitely. Restrict recursion on the same template to 10 levels.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* all: add new typename dirname
The current way to check files under sysfs or proc is:
- define a string to represent each file
- open the file
- pass the fd to write / read / close
The issues above are:
- Need to know what file present on target device
- Need to write openat for each file
With dirname added, which will open one file
in the directory randomly and then pass the fd to
write/read/close.
* all: use typename glob to match filename
Fixes #481
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Currently we have special support for each type of builtin node.
This is complex and does not scale (we may want other types in future).
Prepend the builtin descriptions to the user descriptions instead.
This requires a bit of special support, like not reporting
any builtin descriptions as unused, but otherwise much simpler and more flexible.
Does not produce any diff in generated descriptions.
|
| | |
|
| |
|
|
|
|
| |
Add common infrastructure for syscall attributes.
Add few attributes we want, but they are not implemented for now
(don't affect behavior, this will follow).
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Introduce common infrastructure for describing and parsing attribute
instead of custom per-attribute code scattered across several locations.
Change align attribute syntax from the weird align_N to align[N].
This also allows to use literal constants as N.
Introduce notion of builtin constants.
Currently we have only PTR_SIZE, which is needed to replace
align_ptr with align[PTR_SIZE].
|
| |
|
|
|
|
| |
Add errors3.txt with tests for errors that are produced during generation phase.
Refactor tests to reduce duplication.
Tidy struct/union size errors: better locations and make testable.
|
| |
|
|
| |
Signed-off-by: Paul Chaignon <paul.chaignon@orange.com>
|
| |
|
|
| |
Signed-off-by: Paul Chaignon <paul.chaignon@orange.com>
|
| |
|
|
|
|
|
|
|
| |
Enables the syntax intN[start:end, alignment] for integer ranges. For
instance, int32[0:10, 2] represents even 32-bit numbers between 0 and 10
included. With this change, two NEED tags in syscall descriptions can be
addressed.
Signed-off-by: Paul Chaignon <paul.chaignon@orange.com>
|
| |
|
|
| |
Signed-off-by: Paul Chaignon <paul.chaignon@orange.com>
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
This change adds compiler support for complex path
expressions in len targets. E.g. it allows to refer
to a sibling field as len[parent_struct:field:another_field].
See the docs change for details.
This is just a compiler change.
The feature is not yet supported by the prog package.
|
| |
|
|
|
|
|
|
|
|
|
| |
Ptr type has special handling of direction (pointers are always input).
But buffer type missed this special case all the time.
Make buffer less special by aliasing to the ptr[array[int8]] type.
As the result buffer type can't have optional trailing "opt" attribute
because we don't have such support for templates yet.
Change such cases to use ptr type directly.
Fixes #1097
|
| |
|
|
|
| |
Currently we apply big-endian-ness and bitfield-ness in the wrong order in copyin.
This leads to totally bogus result. Fix this.
|
| | |
|
| |
|
|
|
|
|
| |
checkType is too long and complex.
Move basic type checks and args checks into separate functions.
Update #538
|
| |
|
|
|
|
| |
Currently we have to use 0xffffffffffffffff to represent -1,
and we can't express e.g. -20:20 int range.
Support negative consts to fix both problems.
|
| |
|
|
|
| |
fmt type allows to convert intergers and resources
to string representation.
|
| | |
|
| |
|
|
| |
The size attribute allows to pad a struct up to the specified size.
|
| |
|
|
|
| |
This allows parametrized attributes like size[10].
But this is not used for now.
|
| |
|
|
|
| |
If all union options can be syscall arguments,
allow the union itself as syscall argument.
|
| |
|
|
| |
Can be useful for netfilter descriptions.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Unions with only 1 field are not actually unions,
and can always be replaced with the option type.
However, they are still useful when there will be
more options in future but currently only 1 is described.
Alternatives are:
- not using union (but then all existing programs will be
broken when union is finally introduced)
- adding a fake field (ugly and reduces fuzzer efficiency)
Allow unions with only 1 field.
|
| |
|
|
| |
Needed for netfilter descriptions.
|
| |
|
|
| |
Add stringnoz type.
|
| |
|
|
|
|
| |
"void": type with static size 0
mostly useful inside of templates and varlen unions
can't be syscall argument
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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]])
```
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|