On Mon, Nov 28, 2016 at 6:36 PM, David Sommerseth <
open...@sf.lists.topphemmelig.net> wrote:
> On 28/11/16 23:14, Steffan Karger wrote:
> > As described in trac #751, and shortly after reported by Zhaomo Yang, of
> > the University of California, San Diego, we use memset() (often through
> > the CLEAR() macro) to erase secrets after use. In some cases however,
> the
> > compiler might optimize these calls away.
> >
> > This patch replaces these memset() calls on secrets by calls to a new
> > secure_memzero() function, that will not be optimized away.
> >
> > Since we use CLEAR() a LOT of times, I'm not changing that to use
> > secure_memzero() to prevent performance impact. I did annotate the macro
> > to point people at secure_memzero().
> >
> > This patch also replaces some CLEAR() or memset() calls with a zero-
> > initialization using "= { 0 }" if that has the same effect, because that
> > better captures the intend of that code.
>
> First of all, wonderful that you've looked into an improved memset()
> approach. We need that! I am very happy to see these patches and this
> discussion.
>
> But I am very reluctant to this approach here, to be honest. I do not
> like that we have a two semantics for a overlapping functions; one which
> always ensures memory is wiped (but might be slower) and the other one
> which might or might not wipe the memory (depending on the mood of the
> compiler, etc)
>
> If we "do not care" if a memory region is wiped or not (just that it's
> nice if it happens), then I'd say these are code paths which *do* *not*
> require CLEAR() at all.
>
> If we *know* a certain memory region *must* be cleared, then we do the
> proper call which does what it promises us.
>
> I think we should not have "do not care" code paths, because that
> ambiguity gives us nothing but confusing complexity and such code paths
> bitrots faster than other type of code.
>
> So I'd say that either we move over to secure_memzero() and yank out
> CLEAR() all together. Or we yank out CLEAR() calls where we "don't
> care" and let CLEAR() always do what it tries to promise through its name.
The logic is opposite to what you posit here.
The purpose of secure_memzero is to wipe memory even if its not necessary
for logically correct operation of the program. Especially when its not
necessary for correct logical operation. but is needed to protect privacy.
Whereas when a memory segment must be cleared for correct logic, use the
good old memset and let the compiler optimize it away if/when its smarter
than us. Unless we are discussing Bernsteins "Death of optimizing compilers"
SecureZeroMemory on Windows is not a replacement for ZeroMemory nor is
memset_s a replacement for memset. We need both.
Selva
------------------------------------------------------------------------------
_______________________________________________
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
