Fix Determinism Bug: Avoid Reducing Indices to Reserved Values #2850
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Previously, if an index was equal to `reducerValue + 1`, it would get remapped during index reduction to 1 i.e. `ZSTD_DUBT_UNSORTED_MARK`. This can affect the parsing of the input slightly, by causing tree nodes to be nullified when they otherwise wouldn't be. This hardly matters from a correctness or efficiency perspective, but it does impact determinism. So this commit changes index reduction to avoid mapping indices to collide with `ZSTD_DUBT_UNSORTED_MARK`.
|
Indeed, if I do remember correctly, the previous version was designed to be auto-vectorized, the outcome of which was observed using That being said, the index reducer is hardly a performance bottleneck, so even if this part takes a little bit longer, it shouldn't be materially sensible in any scenario. |
Cyan4973
approved these changes
Nov 9, 2021
|
I've put up a new version that does a superfluous write, but that helps the compiler vectorize the loop (https://godbolt.org/z/Kq4oc139n). |
felixhandte
changed the title
felixhandte
added a commit
to felixhandte/zstd
that referenced
this pull request
Nov 17, 2021
PR facebook#2850 attempted to fix a determinism bug that was uncovered by OSS-Fuzz. It succeeded in addressing that source of non-determinism, but introduced a new one: it was possible, when index reduction occurred, to map indices in the window to the reserved value, which would cause them to be zeroed, potentially altering parsing of the input. This PR addresses this issue. It makes sure that the bottom of the window is always `>= ZSTD_WINDOW_START_INDEX`. I'm not sure if this makes facebook#2850 redundant. I think it's probably still valuable to have that protection as well. Credit to OSS-Fuzz for discovering this issue.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Previously, if an index was equal to
reducerValue + 1, it would get remappedduring index reduction to 1 i.e.
ZSTD_DUBT_UNSORTED_MARK. This can affectthe parsing of the input slightly, by causing tree nodes to be nullified when
they otherwise wouldn't be. This hardly matters from a correctness or
efficiency perspective, but it does impact determinism.
So this Pull Request changes index reduction to avoid mapping indices to
collide with
ZSTD_DUBT_UNSORTED_MARK.I am somewhat concerned that
ZSTD_reduceTable_internal()will be slowernow. I'm not sure how important the speed of this is in practive, but it
looks like it's written to be auto-vectorized, and I'm not sure the new
version is similarly vectorizable.
Credit to OSS-Fuzz for discovery.