Separate state trait/impl for generative fuzzers

[langston-barrett]

Generative fuzzers do not need a corpus. To this end, this commit splits out GenState (trait) and StdGenState (struct) from State (trait) and StdState (struct). The idea is that we will support some notion of a generative fuzzer (perhaps GenFuzzer) that will not rely on having a "current corpus ID". Down the line, we may also want to move input loading/generation/scheduling into a method on GenState that returns a State, see #2200.

This is progress towards #2161.

[langston-barrett]

GitHub Actions has encountered an internal error when running your job.

🙃

[langston-barrett]

cc @tokatoka and @domenukk, who participated in some discussion on this topic.

[domenukk]

I think we should leave State as State and rename your current state to something else, or even just manually spell out the trait bounds where they are needed

[domenukk]

Just mainly because GenState looks pretty ugly 😂
Maybe rename your current state to MutatingState or something?

[domenukk]

Also I don't think we should have one StdState and one StdGenState, let's just do a StdState and a GenerativeState(?)

[domenukk]

Or otherwise use StdState and don't set the current corpus id? Probably something we discussed earlier already, but now if you divide the traits it should work(?)

[langston-barrett]

I'm not 100% sure I understand your suggestions, let me try to paraphrase:

I think we should leave State as State and rename your current state to something else, or even just manually spell out the trait bounds where they are needed

So, in terms of this PR, this would be: rename GenState to State, just remove what's currently called State and add HasCurrentCorpusId manually where needed?

Maybe rename your current state to MutatingState or something?

Again in terms of the code in this PR, the suggestion is: rename {Std,}State to {Std,}MutatingState and Gen{Std,}State to State?

Or otherwise use StdState and don't set the current corpus id? Probably something we discussed earlier already, but now if you divide the traits it should work(?)

So this would be: Keep both traits, but leave StdState as it was before these changes, change use-sites to use GenState where possible, don't set the corpus ID of StdState when doing generative fuzzing?

[domenukk]

Yes to 1 and 3, for 2, I would say Std is always the default/standard thing to use, so we shouldn't have two Std states imho. Instead, let's have one StdState and one GenerativeState (unless suggestion 3 works)

[domenukk]

So ideally we have one State trait that doesn't have a current corpus ID, and one StdState struct that can be used for both use cases. Otherwise, have one StdState and one GenerativeState (for the same traits)

[domenukk]

@langston-barrett what's the status on this? Should I help out/rename the things?

[domenukk]

@addisoncrump we should consider this use case for our big generics cleanup

[domenukk]

Soo... the generics cleanup didn't go too far...
Should we take/finish this PR? @addisoncrump @tokatoka

Imho GenState should be called just State, the current State should be called MutatingState/MutationalState (or similar)

[tokatoka]

there won't be State or GenState after the rework

[domenukk]

Given that the rework is still gonna take some time, why not merge this in the meantime? Otherwise we should close this PR IMHO

[tokatoka]

Merging StdGenState is ok. Adding GenState is no. i'll have to delete it in the future.

[domenukk]

The GenState struct without a generative state trait makes no sense, right?

[tokatoka]

as i said, there's no such trait as State or GenState in the future. it shouldn't exist
and for the code you are swapping State with GenState, but with the current code of LibAFL we simply don't have any contraints on Feedbacks anymore so you have no place to use it

[domenukk]

Why? I think we can still have a State trait that sais "If you want a state, implement the following...", right?

[tokatoka]

because there should not be any downstream struct in libafl that uses State trait.
Such code should be eliminated
One should use HasImported/HasCorpus/... etc. not State. only then can we apply the minimal set of type constraints on structs/traits

[domenukk]

Sure but it might still be useful for people to have one State trait that's the superset of everything they'll have to implement to have a working state

[tokatoka]

idk to me the existence of State is purely wrong
@addisoncrump opinion?