ghost43 has quit [Remote host closed the connection]
ghost43 has joined #bitcoin-core-dev
cmirror has quit [Remote host closed the connection]
cmirror has joined #bitcoin-core-dev
BrandonOdiwuor has joined #bitcoin-core-dev
dermoth has quit [Ping timeout: 268 seconds]
dermoth has joined #bitcoin-core-dev
Guyver2 has joined #bitcoin-core-dev
ghost43 has quit [Remote host closed the connection]
ghost43 has joined #bitcoin-core-dev
Guest63 has joined #bitcoin-core-dev
pyth_ has quit [Ping timeout: 240 seconds]
Guest63 has left #bitcoin-core-dev [#bitcoin-core-dev]
Flow_ has joined #bitcoin-core-dev
Flow has quit [Read error: Connection reset by peer]
pyth has joined #bitcoin-core-dev
jon_atack has joined #bitcoin-core-dev
jonatack has quit [Ping timeout: 264 seconds]
jonatack has joined #bitcoin-core-dev
jon_atack has quit [Ping timeout: 264 seconds]
jon_atack has joined #bitcoin-core-dev
jonatack has quit [Ping timeout: 256 seconds]
jonatack has joined #bitcoin-core-dev
jon_atack has quit [Ping timeout: 252 seconds]
jon_atack has joined #bitcoin-core-dev
jonatack has quit [Ping timeout: 256 seconds]
jonatack has joined #bitcoin-core-dev
jon_atack has quit [Ping timeout: 252 seconds]
Guyver2 has quit [Quit: Going offline, see ya! (www.adiirc.com)]
vasild has quit [Remote host closed the connection]
jespada_ has quit [Ping timeout: 268 seconds]
jespada has joined #bitcoin-core-dev
vasild has joined #bitcoin-core-dev
lbia has quit [Ping timeout: 252 seconds]
<vasild>
dergoegge: I am trying to understand your comment at https://github.com/bitcoin/bitcoin/pull/30211#discussion_r1633223401 "This is what causes the fuzz input to never be interpreted as one continuous sequence of data, which is why mutations that insert pieces of data (e.g. from a dictionary) are ineffective." -- "interpreted" by who? The code in i2p.cpp will behave in the same way if the data is
<vasild>
supplied byte-by-byte by the socket, or e.g. 20 bytes at a time. Do you mean "interpreted" by the fuzz engine?
BrandonOdiwuor has quit [Quit: Client closed]
<vasild>
Is the fuzz engine even aware of how data is consumed from fuzzed_data_provider? My understanding is that what matters is the code coverage and that it is irrelevant whether the fuzzed_data_provider is consumed 1 or 20 bytes at a time.
SpellChecker_ has joined #bitcoin-core-dev
SpellChecker has quit [Ping timeout: 260 seconds]
jon_atack has joined #bitcoin-core-dev
jonatack has quit [Ping timeout: 256 seconds]
<dergoegge>
vasild: I meant interpreted by our harnesses. "never interpreted as one continuous sequence of data": RecvUntilTerminator returns bytes that are not a continuous sequence in the fuzz input it self.
<dergoegge>
For example, if RecvUntilTerminator returns "OK=foobar" then the actual fuzz input will have looked something like "<other bytes>O<other bytes>K<other bytes>=<other bytes>f<other bytes>o<other bytes>o<other bytes>b<other bytes>a<other bytes>r<other bytes>" as opposed to "<other bytes>OK=foobar<other bytes>"
<dergoegge>
This is why a fuzzer has a hard time inserting interesting sequences of data into the input, which makes it less efficient and finding new coverage
puchka has joined #bitcoin-core-dev
<vasild>
Aha, is this because RecvUntilTerminator() calls Recv() (which consumes 1 byte) and then calls Wait() (which will consume further bytes)
Guest59 has joined #bitcoin-core-dev
brunoerg has quit [Remote host closed the connection]
brunoerg has joined #bitcoin-core-dev
<vasild>
dergoegge: if FuzzedSock overrides the RecvUntilTerminator() method from Sock with one that does not call Wait() then that would work as well, I guess
<vasild>
Hmm, is it not all the same for the fuzzing engine whether it will generate "OK<other bytes>" or "O<other bytes>K". The second one could be _the interesting_ sequence (surely that would not work with a dictionary that has "OK")
<dergoegge>
Wait() consumes further bytes and so does FuzzedSock::Recv (i.e. a bunch of ConsumeBool() calls).
<vasild>
right, I see how to be interesting the message has to be dispersed among the input, e.g. instead of "OK" it has to be "O<other bytes>K".
<vasild>
Is it easier or more likely for the fuzz engine to generate "OK<other bytes>" instead of "O<other bytes>K"?
mailman007 has joined #bitcoin-core-dev
mailman007 has quit [K-Lined]
mailman007 has joined #bitcoin-core-dev
mailman007 has quit [K-Lined]
<dergoegge>
We can supply most fuzz engines with a dictionary to use but they also pick up "interesting byte sequences" during program execution by observing e.g. memcmp calls or cmp instructions.
<dergoegge>
In the case of the i2p harness it picks up strings from the SAM protocol like "RESULT=OK" but inserting them into the input directly is useless as the input is not interpreted that way.
<bitcoin-git>
[bitcoin] glozow opened pull request #30272: doc: use TRUC instead of v3 and add release note (master...2024-06-v3-followups) https://github.com/bitcoin/bitcoin/pull/30272
<bitcoin-git>
[bitcoin] vasild opened pull request #30273: fuzz: FuzzedSock::Recv() don't lose bytes from MSG_PEEK read (master...fuzzedsock_unbreak_recv_peek) https://github.com/bitcoin/bitcoin/pull/30273