Constant bitstrings in atoms (for bit-level fuzzing) -- Attempt with Codec::read_bytes
#278
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.
The intended goal of this PR (still WIP) is to add a new kind of atom (actually a variant of a
Term::Variable
) corresponding to constant bitstrings amenable to bit-level fuzzers. The real challenge is to make this work with the current dynamic functions architecture operating on Box that are first dynamically type-checked against the expected type shapes of the arguments. Seedynamic_function::make_dynamic
and thedynamic_fn
macro.For this, we expose the
Codec
traits for all arguments of the dynamic functions in the signature. This way, we can dynamically re-interpret bitstrings as proper messages handled by the function symbols in the signature usingCodec::read_bytes
.Problem 1: in
tlspuffin
, all structs corresponding to data handled by function symbols have theCodec
trait, exceptderived structs like
Vec<handshake::ClientExtension>
,handshake::ClientExtension
has theCodec
trait though.--> it should be possible to simply derive Codec for those as well.
Problem 2: in the current architecture, the dynamic functions operates on pointers to their arguments (since they exist
in the orginal terms anyway). However, we now need to dynamically compute
<typeShape_arg>::read_bytes(bitstring)
andwe would need some sort of "owning reference." Again, this should be fixable.
Problem 3: this is a fundamental issue with this approach (see first item of the "Pros" from [#279]). Since we need to be able to compute
<typeShape_arg>::read_bytes(bitstring)
for all bitstrings post-mutations, we may reject mutations on the basis they crash the parsing by
rustls
, while the possibly morepermissive and buggy PUT parsing routine may accept it. It is still possible to bit-level mutate a larger term
containing the current one but then we loose the structure of other sub-terms we may not be interested to bit-level mutate.
--> To be able to bit-level mutate whole sub-terms without being rejected by the Mapper failures, we must adopt another strategy explained in [#279].