[WIP] fuzz-tests: Add stateful fuzz test for the handshake protocol #8228
Conversation
Changelog-Added: Existing fuzz targets focus on testing individual components of the handshake protocol as defined by BOLT ElementsProject#8. Add a stateful fuzz test to evaluate the protocol's state transitions thoroughly.
There was a problem hiding this comment.
This fuzz target allows acts to be executed out-of-order, so I don't think it's a useful test as-is.
Even if we fix that, I'm skeptical that this target will provide much benefit over the existing single-act fuzz targets, since it is already quite difficult for the fuzzer to successfully complete just a single act. Trying to get the fuzzer to complete multiple acts successfully seems quite unlikely.
That said, if you can demonstrate the fuzzer completing multiple acts in sequence using a coverage report, I would be interested in merging this target.
| struct io_conn *conn = io_new_conn(tmpctx, -1, NULL, NULL); | ||
|
|
||
| while (bytes_remaining > 0) { | ||
| int op = bytes[0] % (STATES_COUNT - 1); |
There was a problem hiding this comment.
I think the -1 prevents RESPONDER_ACT3_RECEIVE from ever being chosen.
| while (bytes_remaining > 0) { | ||
| int op = bytes[0] % (STATES_COUNT - 1); | ||
| bytes++; bytes_remaining--; | ||
| switch(op) { |
There was a problem hiding this comment.
This approach allows the various acts to be executed out-of-order, which should never happen in the real world. I think you would want to execute each act in order rather than letting the fuzzer choose the order.
There was a problem hiding this comment.
I was aiming to simulate a corrupted channel where messages could arrive out of order. But if we abandon that idea, where do we inject the fuzzer’s data? Corrupting individual acts is already well-covered by existing tests, so that approach might not yield much value. Maybe, as you suggested, this fuzz test isn’t particularly worthwhile.
There was a problem hiding this comment.
Incorrect messages can certainly arrive, but the various act handlers should still always execute in the correct order.
Maybe, as you suggested, this fuzz test isn’t particularly worthwhile.
Yeah, if you're interested in stateful fuzzing, I'd suggest looking at something like the funding flow. There's various messages that arrive and change state (e.g., open_channel, funding_signed). It would be good to test that out-of-order messages don't cause any crashes or other bad things.
Existing fuzz targets focus on testing individual components of
the handshake protocol as defined by
BOLT #8. Add a statefulfuzz test to evaluate the protocol's state transitions thoroughly.
Checklist
Before submitting the PR, ensure the following tasks are completed. If an item is not applicable to your PR, please mark it as checked: