aboutsummaryrefslogtreecommitdiffstats
path: root/pkg/compiler/testdata
Commit message (Collapse)AuthorAgeFilesLines
* prog: pkg/compiler: docs: introduce the `no_squash` attributeAlexander Potapenko2025-09-091-0/+1
| | | | | | | | | | | | | | | | | The `no_squash` per-syscall attribute prevents the fuzzer from generating squashed arguments to a particular syscall. This is particularly helpful for pseudo-syscalls with elaborate arguments that are hard to reason about when they are squashed - e.g. for syz_kvm_add_vcpu() that takes a SYZOS program as an input. I've considered an alternative solution that prohibits ANY for all pseudo-syscalls. But there is a bunch of existing programs (both the tests and the repros) for syscalls like syz_mount_image() for which the benefit of not passing ANY is not immediately obvious. I therefore decided to go with an explicit attribute that can later be enforced for every pseudo-syscall at compile time.
* pkg/declextract: generated single openat for all related filesDmitry Vyukov2024-12-111-25/+1
|
* prog: annotate image assets with fsck logsFlorent Revest2024-12-092-0/+6
| | | | | | | | | | | | | | | | | | 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.
* pkg/compiler: allow manual consts to override auto-extracted constsDmitry Vyukov2024-11-264-0/+20
| | | | | | | | | | | | | | | | | | | | Currently if const values in 2 .const files have different value, the compiler produces an error. This is problematic for auto-extacted consts since we extract them for only 1 arch now. So if a const has different values for different arches, auto-extacted consts may not reflect that, and we can get a mismatch with manual descriptions that has correct values for all arches. So if both manual and auto-extacted consts have different values, silently prefer the manual ones. I've tried to do some whitelisting of consts during auto-extaction, but the list is large and changing over time. This solution is not perfect since the manual descriptions may have a bug, and the mismatch is actually pointing to that bug. Maybe in future we could extract for all arches separately, or do something else. But let's do this for now.
* pkg/compiler: allow recursion via arraysDmitry Vyukov2024-11-182-9/+33
| | | | | Permit structs to recursively contain itself in arrays. This is needed for netlink. Amusingly several netlink policies contain itself.
* compiler: support constants in conditional fieldsPaul Chaignon2024-09-092-2/+4
| | | | | | | | | | | | | | | | | | This commit adds support for using the value of constants in conditional fields in addition to integers and flags. Intuitively, this probably looks like it shouldn't be needed: constants are known so the condition can be resolved ahead of time. It is however useful in the case of templates (example in the next commit) where the type of a field may be interchangeably an integer or a constant: type example_t[TYPE] { f1 TYPE f2 int32 (if[value[f1] == 3]) } type example1 example_t[int64] type example2 example_t[const[0, int64]] Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
* pkg/compiler: updated testdata for 'fmt'Igor Chervatyuk2024-07-081-0/+2
| | | | | New usecases for 'fmt' arguments after enabling 'proc' type in context of structures outlined in testdata/all.txt.
* executor: remove noshmem modeDmitry Vyukov2024-06-041-1/+1
| | | | | | | | | All OSes we have now support shmem. Support for Fuchia/Starnix/Windows wasn't implemented, but generally they support shared memory. Remove all of the complexity and code associated with noshmem mode. If/when we revive these OSes, it's easier to properly implement shmem mode for them.
* compiler: support using int flags in field conditionsPaul Chaignon2024-03-011-2/+2
| | | | | | | | | | | | | | | | | | | Commit ed571339c6ff ("pkg/compiler: support if[expr] attributes") added support for conditional fields in structs and unions. Conditions however cannot refer to flags, as in the following example: struct { f0 flags[some_flags, int32] f1 int32 (if[value[f0] & FLAG1]) } [packed] It will fail to compile with: flags does not refer to an integer This commit adds support for that syntax. Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
* pkg/compiler: support if[expr] attributesAleksandr Nogikh2024-02-194-0/+119
| | | | | | | | | | | | | | | | | | | 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 ]
* pkg/compiler: extend parent reference support in lenAleksandr Nogikh2024-02-192-12/+27
| | | | | | | | | | | | Earlier only len[parent, T] was supported and meant the size of the whole structure. Logically, len[parent:b, T] should be equivalent to just len[b, T]. Let len[parent:parent:a, T] refer to the structure that encloses the current one. Support len fields inside unions.
* compiler: require nested flags to be at the end of the listPaul Chaignon2023-12-051-0/+3
| | | | | | | | | | | | | | | | | | | | | | | 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>
* compiler: support nested string flags definitionsPaul Chaignon2023-12-051-0/+4
| | | | | | | | | This commit adds support for flags definitions such as: flags1 = "string1", "string2" flags2 = flags1, "string3" Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
* compiler: error on circular dependencies in flag definitionsPaul Chaignon2023-12-051-0/+6
| | | | | | | | 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>
* compiler: support nested int flags definitionsPaul Chaignon2023-12-051-0/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* compiler/testdata: add missing error casesPaul Chaignon2023-11-292-1/+16
| | | | | | | 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>
* compiler: prohibit homonymous flags and constsPaul Chaignon2023-11-281-0/+3
| | | | | | | | Since both flags and consts can be used as type-options for integers, we want to avoid ambiguity by preventing a flag and a const from having the same name. Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
* compiler: support const as int first argumentPaul Chaignon2023-11-283-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* compiler: support flags as int first argumentPaul Chaignon2023-11-282-4/+8
| | | | | | | | | | | | | | | | | | | 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>
* compiler: support type args with mixed kindsPaul Chaignon2023-11-281-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* pkg/compiler: prohibit not DirIn resources inside fmtAleksandr Nogikh2023-10-061-0/+4
| | | | | | | | The problem mentioned in the previous commit is actually not only ANY-specific, it's only by a happy coincidence that all our descriptions already avoided such situations. Enforce this rule at the compilation stage.
* pkg/compiler: support (in) for union fieldsAleksandr Nogikh2023-10-061-1/+2
| | | | | | | | | | | | | 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.
* prog, pkg/compiler: add `BufferCompressed` buffer type & `compressed_image` ↵Hrutvik Kanabar2022-11-213-0/+33
| | | | | | | | | | | | | | | | | | | | | | | | 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.
* pkg/ast, pkg/compiler: support per-file metadataDmitry Vyukov2022-04-292-0/+8
| | | | | | | | | | | | | | | | | | | | | 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
* pkg/compiler: require stricter resource constructorsDmitry Vyukov2022-01-111-0/+8
| | | | | | | | | | | | | Don't consider syscalls that return resources in unions/arrays as constructors. Unions and arrays are problematic because we don't have directed generation in prog.randGen.createResource() and can fail to generate a syscall that returns a particular resource (generate a wrong union option that does not contain the necessary resource). This leads to the following panics: panic: failed to create a resource ifindex with ioctl$sock_SIOCGIFCONF Require each resource to have a constructor syscall that returns the resource outside of unions/arrays.
* pkg/compiler: fix error message spellingDmitry Vyukov2022-01-111-4/+4
| | | | Add missing space before brackets.
* pkg/compiler: prohibit use of len/flags/const/proc types in out fieldsDmitry Vyukov2022-01-111-1/+8
| | | | These types in explict out fields is either unnecessary details or bugs in descriptions.
* pkg/compiler: prohibit use of direction attribute on union fieldsDmitry Vyukov2022-01-112-8/+7
| | | | | | 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.
* pkg/compiler: add out_overlay field attributeDmitry Vyukov2022-01-113-1/+41
|
* pkg/compiler: warn about confusing comments that fake directivesDmitry Vyukov2021-11-121-0/+5
| | | | | | | | 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.
* pkg/compiler: add more tests for templatesDmitry Vyukov2021-10-051-0/+20
| | | | Add 2 more tests for recursive templates.
* pkg/compiler: fix infinite recursion in template instantiationDmitry Vyukov2021-10-051-0/+5
| | | | | | | | | | | | | 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.
* pkg/compiler: add glob typeJoey Jiaojg2021-05-262-1/+9
| | | | | | | | | | | | | | | | | | | | * 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
* pkg/compiler: check for flags with all equal valuesDmitry Vyukov2020-11-131-0/+6
| | | | | | There is no point in having flags when values are equal. This can only mean a typo or other bug. Check for such cases and fix 3 existing precedents.
* pkg, prog: add per-field direction attributeNecip Fazil Yildiran2020-08-133-6/+108
|
* pkg/compiler: check for unused resourcesDmitry Vyukov2020-08-041-1/+4
| | | | | | | | | | If a resource is never used as an input, it is not useful. It's effectively the same as using an integer. Detect such cases, they are quite confusing. Fix all existing errors in descriptions. This uncovered some interesting bugs as well, e.g. use of a completely unrelated fd subtype after copy-paste (while the resource that was supposed to be used there is completely unused).
* pkg/compiler: fix crash on fmt[flags]Dmitry Vyukov2020-07-231-0/+3
| | | | | | | Flags with only 1 value 0 are transformed to ConstType. Fmt did not expect that. Fixes #1965
* pkg/compiler: simplify and enhance handling of builtinsDmitry Vyukov2020-05-051-2/+2
| | | | | | | | | 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.
* pkg/compiler: error on duplicate attributesDmitry Vyukov2020-04-191-0/+1
|
* prog: introduce call attributesDmitry Vyukov2020-04-192-0/+6
| | | | | | 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).
* pkg/compiler: refactor attribute handlingDmitry Vyukov2020-04-193-11/+8
| | | | | | | | | | | | 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].
* pkg/compiler: check that flags values fit into base typeDmitry Vyukov2020-03-171-0/+3
| | | | | | | | flags[foo, int8] foo = 0x12345678 is always an error, detect these cases. Found some bugs in mptcp, packet sockets, kvm.
* pkg/compiler: check that const values fit into base typeDmitry Vyukov2020-03-172-0/+7
| | | | | const[0x12345678, int8] is always an error, detect these cases. Found some bugs in mptcp, socket proto and fuchsia fidl descriptions.
* pkg/compiler: add tests for generation phaseDmitry Vyukov2020-03-173-0/+24
| | | | | | 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.
* pkg/compiler: ensure consistency of syscall argument typesDmitry Vyukov2020-03-171-52/+52
| | | | | | | | | | | | | | | | | | Ensure that we don't have conflicting sizes for the same argument of the same syscall, e.g.: foo$1(a int16) foo$2(a int32) This is useful for several reasons: - we will be able avoid morphing syscalls into other syscalls - we will be able to figure out more precise sizes for args (lots of them are implicitly intptr, which is the largest type on most important arches) - found few bugs in linux descriptions Update #477 Update #502
* pkg/compiler: don't specify syscall consts for test OSDmitry Vyukov2020-03-171-2/+2
| | | | This is just tedious. Fabricate them on the fly.
* pkg/ast: introduce hex-encoded string literalsDmitry Vyukov2020-02-102-0/+4
| | | | | | | | | | | | | The stringnozescapes does not make sense with filename, also we may need similar escaping for string flags. Handle escaped strings on ast level instead. This avoids introducing new type and works seamleassly with flags. As alternative I've also tried using strconv.Quote/Unquote but it leads to ugly half-escaped strings: "\xb0\x80s\xe8\xd4N\x91\xe3ڒ,\"C\x82D\xbb\x88\\i\xe2i\xc8\xe9\xd85\xb1\x14):M\xdcn" Make hex-encoded strings a separate string format instead.
* pkg/compiler: fix alignment of string-formatted valuesDmitry Vyukov2019-12-201-1/+6
| | | | | | We used size as alignment, this is very wrong. Found thanks to syz-check. Update #590
* pkg/compiler: fix incorrect alignment calculation for paddingDmitry Vyukov2019-12-181-1/+10
| | | | | | | | | | | | | | We assumed that for ConstType alignment is equal to size, which is perfectly reasonable for normal int8/16/32/64/ptr. However, padding is also represented by ConstType of arbitrary size, so if we added 157 bytes of padding that becomes alignment of the padding field and as the result of the whole struct. This affects very few structs, but quite radically and quite important structs. Discovered thanks to syz-check. Update #590
* pkg/compiler: define fileoff templatePaul Chaignon2019-11-011-2/+2
| | | | Signed-off-by: Paul Chaignon <paul.chaignon@orange.com>
generated by ggit (джигит) mrf-deployment (git 2.46.0) at 2026-03-11 22:34:49 +0000