Rayhaan JaufeerallyandClaude Fable 5.1
1f89fb4b13
The first part of RPKI origin validation (RFC 6811): the data and how it gets here. Nothing uses it yet. VrpTable holds the validated ROA payloads and says whether a route is valid, invalid or not found. It is a binary trie in one allocation with a short cut past the first sixteen levels; a lookup against 600,000 entries takes about 40 ns for random addresses. A table is built once and not changed: when the data changes another takes its place. rtr is the RPKI-to-Router protocol's PDUs (RFC 8210, and version 0 of RFC 6810), as bytes and back, without I/O. Lengths are checked from the header, before the rest of a PDU is waited for. The client keeps the table in step with a validator's cache. It asks for everything once and then for changes, when the cache notifies and at the refresh interval. An answer takes effect only when it is complete and consistent. Each update says which VRPs came or went, so that only the routes they cover need looking at again. A cache that fails is retried and the next one tried; the data is used meanwhile, and dropped if no cache confirms it within the expire interval. A cache that speaks only version 0 is spoken to in version 0. Tests: the cases of RFC 6811, a property test of the trie against the plain definition, round-trip and hostile-input properties for the codec, a fuzz target, and the client against a scripted cache. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
1.8 KiB
Fuzz targets
Coverage-guided fuzzing of everything that reads input we do not control.
The property tests (cargo test, e.g. crates/packet/tests/properties.rs)
check the same things on generated input and run on every build; these
targets go further by letting libFuzzer follow code coverage for as long as
you leave them running.
| Target | Input |
|---|---|
message |
Raw bytes as they come off a TCP connection |
message_body |
A message body behind a correct header (reaches the body parsers) |
prefix_text |
A prefix as text |
config |
The configuration file |
rtr |
A stream of RTR PDUs, as an RPKI cache sends them |
For the two message targets a finding is either a panic, or a message the decoder accepted that cannot be written and read back as itself.
Running
libFuzzer needs a nightly toolchain and cargo-fuzz:
rustup toolchain install nightly
cargo install cargo-fuzz
Then, from this directory:
cargo +nightly fuzz run message_body corpus/message_body seeds/message_body -- -max_total_time=300
The first directory is the working corpus, which the fuzzer adds to and
which is not checked in. seeds/ holds a few valid inputs to start from.
Leave out -max_total_time to run until interrupted.
When it finds something
The input is saved under artifacts/<target>/. Reproduce it with
cargo +nightly fuzz run message_body artifacts/message_body/crash-...
Fix the bug, and add a unit test with the input next to the code it broke,
so that cargo test keeps it fixed without anyone having to run the fuzzer.