Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Add SecBlock member to track number of elements to zeroize (Issue 346)
By default the member, named m_mark, is set to the maximum number of elements. If SetMark() is called, then m_mark is adjusted. Upon deallocation and zeroization, STDMIN(m_size, m_mark) elements are zeroized. We wanted to use a high water mark, but we could not track the writes to the allocation. operator[] would have been OK, but ::memcpy would have been problematic
- Loading branch information
Showing
2 changed files
with
226 additions
and
112 deletions.
There are no files selected for viewing
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
Oops, something went wrong.
a49cb08
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.
This check-in adds a member to track how many elements to zeroize. If a user does nothing, then former behavior is preserved. If
SetMark
is called, then the number of elements wiped can be changed.The next check-in will use
SetMark
to avoid the extra zeroization in @ngg's report. Effectively, before the throw,SetMark(0)
will be called on the SecBlock to avoid zeroizing the unintialized memory.While not readily apparent, this allows us to tend to @ngg's report and preserve streaming interfaces that would otherwise throw too early before all the data arrived.
@denisbider uncovered additional cases of runts and underruns, like in
Integer::Decode
. Those are imperative "parse this integer now", and they don't require the new behavior because they are not streaming data. We simply need to audit for the uses and throw as required.Also see Issue 346.