This repository has been archived by the owner on May 7, 2020. It is now read-only.
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Replace ZeroMemory() with SecureZeroMemory(). The MSDN article for Ze…
…roMemory says: "To avoid any undesired effects of optimizing compilers, use the SecureZeroMemory function."
- Loading branch information
Showing
36 changed files
with
96 additions
and
96 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
0533530
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.
It seems as if "undesired effects of optimizing compilers" were mainly security issues when clearing e.g. a password cache with ZeroMemory(), since the call could be delayed or omitted completely by an optimizing compiler were appropriate (see MSDN article for SecureMemoryCopy() - http://msdn.microsoft.com/en-us/library/windows/desktop/aa366877.aspx).
From what I understand functionality isn't affected at all when using a simple ZeroMemory() instead of SecureMemoryCopy(), though the code could be optimized in the first case to run faster. ZeroMemory() is therefore probably still favorable.
0533530
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.
You misunderstand optimization for ZeroMemory.
In this case, you should not use SecureZeroMemory.
0533530
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.
SecureZeroMemory need for passwords and other private data. There is no reason to use it to clean the newly declared variables.
0533530
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.
It does not hurt in either way.
0533530
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.
Your decision...
I'd prefer the potentially faster ZeroMemory() as long as I don't have any real world performance measurements at hand (or did you actually do some benchmarks?).
0533530
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.
I don't care about it so no.
0533530
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.
FYI:
"The RtlSecureZeroMemory function is written using "volatile". This is a huge hammer and tells the complier "hands off this code, you may think you know what it does, but you don't". Many years ago when Microsoft was doing internal security audits they found that the optimizing compiler was removing memset() operations that were required for security. This page http://msdn.microsoft.com/en-us/library/aa366877(VS.85).aspx gives a hand wavy example of what I’m referring to. In these cases the intent of the programmer was to write over a block of memory to hide its contents from snooping, however the compiler could detect that the memory wasn’t read by the program after that (or something similar that made the memset appear removable) and it removed the memset. The Windows team decided to provide an easy API for developers to use that guaranteed that the memory would be written no matter what. Thus, the SecureZeroMemory API was born. This function is not intended to be used for performance critical code; it is intended to be used for security critical code. Its usage of volatile has the effect of turning off many of the optimizations that would fire on normal code. Compare the output of the compiler when you replace the call to "SecureZeroMemory" with a call to the less security zealous "ZeroMemory" function."
(From http://connect.microsoft.com/VisualStudio/feedback/details/686811/weird-suboptimal-code-emitted-for-securezeromemory)
So it's definitely the wrong function for variable initialization...
0533530
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.
I'm not sure either that the SecureZeroMemory is a good idea for our use case. I think it's being overzealous knowing the potentially bad side effects.
0533530
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.
I think it's fine and it should be used when we need to use ZeroMemory. ZeroMemory can be optimized and thus ignored, and even though we don't handle sensitive data I see no reason to use it when we know that this can happen. Otherwise just don't use it at all.
0533530
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.
Well we use ZeroMemory only for variable initializations, I wouldn't call that security critical while performance can matter.
But anyway probably it doesn't matter much so if you really think SecureZeroMemory is important.
0533530
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.
0533530
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.
@XhmikosR I appreciate your efforts, but in this case you've misunderstood the MSDN article. If there are no objections I'll revert this commit.
0533530
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.
There are. I see no reason to use ZeroMemory instead of SecureZeroMemory.
0533530
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.
We should only force the compiler to ignore optimizations when it is really necessary, or else we might make it ignore optimizations which are actually useful.
0533530
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.
But there is also no reason to use SecureZeroMemory instead of ZeroMemory
0533530
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.
Unless you have numbers that prove that SecureZeroMemory is faulty or breaks something, it should be preferred. That's all I'm saying and I'm still against reverting it unless I see some proofs.
0533530
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.
Can you prove that ZeroMemory is faulty or breaks something in our code? I see no reason to prefer SecureZeroMemory here.
We know very well now where SecureZeroMemory should be used and that is just not the case here. The reasons you are giving to use SecureZeroMemory are no longer consistent with the MSDN article.
Also it has a performance penalty: http://connect.microsoft.com/VisualStudio/feedback/details/686811/weird-suboptimal-code-emitted-for-securezeromemory.
Again a Microsoft employee comments there that SecureZeroMemory has been made with "security above all else". We don't need security, we need performance.
0533530
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.
No I can't prove that, the same way you don't prove the opposite.
For me this discussion is over; unless I see facts that it breaks something or that there is a so important performance penalty, SecureZeroMemory will stay.
0533530
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.
I've never seen anybody having such a hard time admitting a mistake, especially if it's a mere trifle like in this case.
XhimikosR, your sole argument in this discussion is basically that you don't see a reason to prefer one over the other and therefore you're not going to revert this commit. At the same time every other person that commented has clear objections against using SecureZeroMemory. The conclusion should be obvious...
Regarding performance: From what we now (MSDN) SecureZeroMemory is at best as fast as ZeroMemory, but it's possibly and likely slower. That's basically already enough of a proof to avoid SecureZeroMemory if possible.
Besides that ZeroMemory is the default way to do it. If you want to use SecureZeroMemory (for no obvious reason) it's rather your turn to prove it's not slower!
0533530
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.
@Ede123: no need for lot of words especially from people who are outside of the team and cannot follow our internal discussions.
0533530
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.
@Ede123 The commit has already been reverted, pressing on this any further won't help.
@XhmikosR Please try not to take the discussion personally, we're all trying to make sure the code is as best as it can be just like you. There is no need to get defensive about your changes, just look at the facts as they stand.