On 18.10.18 16:00, Daniel Stenberg wrote:
> Any suggestion on how to do this and make sure the compiler doesn't
> remove the memset() ?

I'm not that familiar with compiler optimization, so I'm not sure if I
can bring that many useful ideas. But at least for Windows there seems
to be a SecureZeroMemory function that can be used. However, this does
not help for Linux. According to HackerNews [1] we can use inline
assembler to ensure that the compiler does not optimize the memset away.
But the presented solution is for GNU C, so it should work for gcc and
clang, but it is not really a portable solution; depending on your
requirements.
I"m afraid that a fully portable solution involves hoping that most
compilers won't optimize that much. In this case the approach from [2]
still seems viable. It might not be fully foolproof, but it is
questionable if a compiler will really optimize that much.
I guess there might be a gap between theory and practice. In theory we
cannot ensure that a compiler does not remove the memset, however in
practice it should work in almost any cases (at least I hope so). Do you
know of any case where a compiler really removed a memset (a "normal"
one as well as something like [2])?

[1]: https://news.ycombinator.com/item?id=8271205
[2]: http://www.daemonology.net/blog/2014-09-05-erratum.html

> Also, are you suggesting we clear the memory for all frees? If yes, then
> we need to keep track of the sizes somehow and if no, then we need to
> figure out which ones and deal with the appropriately.

I think it would be best to clear memory for all frees. This way it's
also easier to ensure that all sensitive memory is cleared and that none
is forgotten. But this might not be necessary.
I think the most important part are all strings in a request (the body
as well as all headers). Internal allocations for structs, etc. are not
that sensitive I guess.
Clearing zero terminated strings is also easier, because we easily can
get the length. But yes, if all allocated memory should be freed, we
have to keep track of the size. A simple way to do so is using an custom
allocator that allocates more memory as requested and saves the size in
the memory before the pointer it returns. I think malloc does something
similar, but I guess we cannot rely on that and access the memorysize
that way.

> Can we come up with a way to measure this if we are doing this right or
> not?

I think it's hard to measure. Seems easiest to me to simple use a custom
free for all allocated memory or for all strings.
And measuring if the cleared memory was really cleared is also not that
trivial.

--
Gabriel

-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html