-
Notifications
You must be signed in to change notification settings - Fork 37.7k
fuzz: Test headers pre-sync through p2p interface #28043
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. Code CoverageFor detailed information about the code coverage, see the test coverage report. ReviewsSee the guideline for information on the review process.
If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update. ConflictsReviewers, this pull request conflicts with the following ones:
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first. |
Draft until #27499 is in. |
4407469
to
0aca787
Compare
Rebased and un-drafted, ready for review! |
0aca787
to
8a7feb6
Compare
8a7feb6
to
f718a2c
Compare
6b4edf3
to
6bac3ba
Compare
|
924e6ea
to
2b746ab
Compare
Thanks! rebased. |
Concept ACK. Planning on reviewing soon. |
Needs rebase (silent merge conflict). |
2b746ab
to
a955242
Compare
Thanks, rebased |
bool CheckProofOfWork(uint256 hash, unsigned int nBits, const Consensus::Params& params) | ||
{ | ||
if (g_check_pow_mock) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should probably have some belt-and-suspenders check that we're 100% not running on mainnet, maybe based on the contents of params
and whatever applicable global.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
An alternative to the mocking would be to use FUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION
in all places that call CheckProofOfWork
(i.e. validation, mining) since there is literally zero benefit in having this be a blocker for fuzzing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Opened #29305 to discuss, I think it actually makes more sense than the mocking
a955242
to
4516b45
Compare
It's been more than 6 months since I opened this without substantial review, so closing. Let me know if anyone is actually interested in reviewing and I'll reopen. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
just fyi, I started reviewing at some point, my problem was that I don't like test-specific / mocking code in production code (especially the consensus-critical parts), so I wasn't really comfortable (concept)-acking it.
On the other hand, I didn't see a better way to do it and fuzzing is great obviously...
As a result, I was undecided and didn't write anything. Maybe it'd be worth to have a general discussion about the extent of mocking / test-specific production code we want as a project, since there are obviously both advantages and disadvantages to it. If there was a general consensus that these kind of mocks are fine I'd be happy to review/ack the actual fuzz target.
I'd say they are fine, if there is no better way. With global functions and variables, I think the only way to mock them is also via a global approach. Here, adding the |
a97f43d fuzz: Add harness for p2p headers sync (marcofleon) a0eaa47 Add FUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION in PoW check (marcofleon) a3f6f5a build: Automatically define FUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION for fuzz builds (marcofleon) 0c02d4b net_processing: Make MAX_HEADERS_RESULTS a PeerManager option (marcofleon) Pull request description: This PR reopens #28043. It's a regression fuzz test for #26355 and [a couple bugs](ed6cddd) that were addressed in #25717. This should help us move forward with the [removal of mainnet checkpoints](#25725). It seems like the main concern in #28043 was the global mock function for proof of work. This PR aims to be an improvement by replacing the previous approach with a fuzz build configured using `FUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION`. This ensures that the simplified test code will never be in a release binary. If we agree this is the way to go, there are some other places (for future targets) where this method could be used. In this target, PoW isn't being tested, so the goal is to bypass the check and let the fuzzer do its thing. In the other harnesses where PoW is actually being fuzzed, `CheckProofOfWork` is now `CheckProofOfWorkImpl`. So, the only change to that function is in the name. More about `FUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION` can be found at https://llvm.org/docs/LibFuzzer.html#fuzzer-friendly-build-mode and https://github.com/AFLplusplus/AFLplusplus/blob/stable/docs/fuzzing_in_depth.md#d-modifying-the-target. ACKs for top commit: naumenkogs: ACK a97f43d dergoegge: reACK a97f43d instagibbs: tested ACK a97f43d brunoerg: ACK a97f43d Tree-SHA512: 60b0bc6aadd8ca4c39db9cbba2da2debaaf68afcb6a8dd75c1ce48ca9e3996948fda8020930b6771a424e0f7c41b0b1068db4aa7dbe517f8fc152f1f712058ad
This PR adds a regression fuzz test for #26355 and some of the bugs found during review of #25717.
Should give us more confidence in doing #25725.