Common: make derived key buffer alignment explicit in CreateVolumeHeaderInMemory - #1843
Open
bernardladenthin wants to merge 1 commit into
Open
Conversation
…derInMemory ReadVolumeHeaderWithAbort declares its derived key buffer with TC_DERIVED_KEY_BUFFER_ALIGNMENT, the equivalent buffer in CreateVolumeHeaderInMemory did not. The buffer already ends up 16-byte aligned because the KEY_INFO object above it raises the section alignment, so this changes no generated code - it only removes the dependence on that coincidence.
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
What
One line in
src/Common/Volumes.c:Why
ReadVolumeHeaderWithAbortdeclares its derived key buffer withTC_DERIVED_KEY_BUFFER_ALIGNMENT(introduced in #1526), and theKEY_INFOobject three lines above this one usesTC_KEY_INFO_BUFFER_ALIGNMENT. The equivalent buffer inCreateVolumeHeaderInMemorywas the only one left without an explicit alignment.This is not a bug fix
The buffer already ends up 16-byte aligned, because the
KEY_INFOobject above it raises the alignment of the whole section. Verified withdumpbinon the emitted object: section alignment 16,dkat offset0x1F0(= 16 × 31).Consequently the generated code does not change — compiling
Volumes.cbefore and after with identical flags produces a byte-identical.obj(MSVC/Brepro, Release|x64). The change only removes the dependence on that coincidence.Verification
/W4—Volumes.c,InPlace.c,BootEncryption.cpp,Tests.c: clean/W4 /WX—DriveFilter.c,Volumes.c,Tests.c: cleanVolumes.objSHA-256 unchanged before/afterveracrypt --test: passNote that
src/Common/Volumes.cis not part of the Linux build, so the Linux run only guards against collateral damage.