[KFTF]: introduce domain constraints #3
Draft
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
added 3 commits
July 4, 2025 08:34
these via sysfs, and how they can be parsed from the vmlinux binary as well.
constraints to avoid weird errors occurring during parsing.
ethangraham2001
force-pushed
the
kftf_domain_constraints
branch
from
f988367 to
581f240
Compare
| static int write_input_cb_common(struct file *filp, const char __user *buf, | ||
| size_t len, loff_t *off, void *arg, | ||
| size_t arg_size) | ||
| // XXX: why can't we use without the attribute unused anymore?? |
There was a problem hiding this comment.
Maybe because this function is inlined at every callsite?
| * | ||
| * Note: if this struct is not a multiple of 64 bytes, everything breaks and | ||
| * we get corrupted data and occasional kernel panics. To avoid this happening, | ||
| * we enforce 64 Byte alignment and statically assert that this struct has size |
There was a problem hiding this comment.
I am afraid we'll have bigger structs in the future (e.g. to list a set of possible values).
Why does everything break?
Maybe we can put the struct length at its beginning?
| "struct kftf_constraint should have size 64"); | ||
|
|
||
| /** | ||
| * __KFTF_DEFINE_CONSTRAINT - defines a fuzz test constraint linked to a given |
There was a problem hiding this comment.
Nit: you normally don't write doc comments for internal macros/functions.
added 2 commits
July 8, 2025 18:27
strings) and a field being the length of another.
There was not any mechanism in place in the KFuzzTest for distinguishing between value pointers and array pointers in fuzz test inputs. This information is difficult to parse without additional semantic information on the context. We introduce a new KFTF_ANNOTATE_ARRAY macro that annotates a field in a KFuzzTest input struct as an array, removing this ambiguity.
ethangraham2001
force-pushed
the
kftf_domain_constraints
branch
from
4a7f93e to
8e1f787
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description (WIP)
We want to be able to express domain constraint programmatically via macro as we do for exposing kernel fuzz tests with the framework.
This PR, for now, introduces several new macros that define constraint structures with static types. These should be readable in the
.kftf.constraintssection of the VM Linux binary (see PR ethangraham2001/syzkaller#2 on the syzkaller fork). The idea is to also expose these via the debugfs in one or more entries that can be parsed by fuzzing engines.This PR also introduces a few macros for defining annotations - annotations allow us to annotate fields with more information in a way that isn't reflected in a type. For example, a
const char *field may be an array of bytes, or may be a logical string that is null-terminated. We thus allow theFUZZ_TESTauthor to annotate fields in the input structures. We currently supportAny validation of such annotations is left up to the fuzzing engine. For example a length field should be a numerical type, and a string should have base type
(const) char *.