fix soundness concern in h1 decoder #1614
Merged
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.
PR Type
Unsoundness Fix
PR Checklist
Overview
From all the sources I can see, its never okay to do:
unless
T
isMaybeUninit<T>
(see the nomicon).Parsing HTTP headers in the h1 decoder currently uses code like this which Miri flags as unsound. See this playground for a simplified example.
This PR removes all the unsound memory initializations in h1 decoder and opts to use a pre-filled const array to be handed to
httparse
.I believe this to be the fastest sound solution without requiring changes to
httparse
. (Aside: I think in theory,httparse
could provide a parse function that fills in a MaybeUninit header array and allows caller to declare the array intitialized with the number of headers it parsed. You can imagine it's data flow with the setup in this modifed playground. However, I opted for the safer approach for now)Benchmark code is included. Using test cases from
httparse
we see the following regressions:Short Response:
Realistic Response: