Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to zero a buffer

daemonology.net

Post reply on HN
Print view View original

161–170 of 216 posts

Re: How to zero a buffer

#161

Post by akavel »

StavrosK wrote: post #155
joelangeway wrote: post #154

Earlier quoted context omitted.

Yes, it refers to a memory location, without implying anything about the semantics of the bits located at that location. You can't dereference or assign to the location because you don't know the type at that location. You can however assign that pointer to a typed pointer variable to actually read or write to that memory location. This is useful when you really care about the bits of memory but you're variable point…

Hmm, I'm a bit confused. Isn't that a function call, rather than a function declaration? If it's a function call, it's passing a bunch of types in, which I thought was not valid C?

Ah, now I get your question. So, it is a function declaration, not a function call. Um, sorry: a declaration of a pointer to a function, where this function would take as arguments: some (unnamed) void pointer, some (unnamed) int value, and some (unnamed) size_t value; and would return a void pointer.

Um; then there's the equal sign, so this is not only a declaration, but a definition too; but definitely not a call.

A call is further down in the original blogpost, in the below line:

    (memset_ptr)(p, 0, len);

Re: How to zero a buffer

#162

Post by StavrosK »

akavel wrote: post #161
StavrosK wrote: post #155

Earlier quoted context omitted.

Hmm, I'm a bit confused. Isn't that a function call, rather than a function declaration? If it's a function call, it's passing a bunch of types in, which I thought was not valid C?

Ah, now I get your question. So, it is a function declaration, not a function call. Um, sorry: a declaration of a pointer to a function, where this function would take as arguments: some (unnamed) void pointer, some (unnamed) int value, and some (unnamed) size_t value; and would return a void pointer. Um; then there's the equal sign, so this is not only a declaration, but a definition too; but definitely not a call.…

Oh! A pointer to a function! Aha, I didn't know that was valid, thanks!

Re: How to zero a buffer

#163

Post by dllthomas »

sharpneli wrote: post #131
dllthomas wrote: post #86

Earlier quoted context omitted.

From the article, "Some people will try this with secure_memzero in a separate C file. This will trick yet more compilers, but no guarantees — with link-time optimization the compiler may still discover your treachery." https://gcc.gnu.org/wiki/LinkTimeOptimization http://llvm.org/docs/LinkTimeOptimization.html

Move the func into a dynamically linked library. Thanks to the performance requirements of dynamic linking it's going to be a really long time until we have dynamic linker peeking into .so files and checking what a func does.

That certainly does it, yes. Though that's more complicated than the solution offered here, and of course now the right thing to do is just a memset_s.

Re: How to zero a buffer

#164

Post by kazinator »

__david__ wrote: post #134
kazinator wrote: post #101

Earlier quoted context omitted.

I've just been digging through the C99 standard (official) and the N1570 (final C11 draft) and have come to the conclusion that these optimizations break the language. This is probably not something you should be compiling your OpenSSL shared library or SSH with. A C program consists of translation units which may be preserved in translation form. That happens in translation phases 1 through 7. Multiple translation u…

> Though it is just an example, and not normative, it is very clear from the wording that the locus of valid optimizations is the translation unit. I don't think that's clear at all. As you said, it's just an example. > Phase 8 only consists of resolving references; the last semantic analysis takes place in phase 7. Why do you think that the only place you can optimize is during the "semantic analysis" phase? To me t…

The word "all" in "all such translator output" seems to rule out removing any code, such as the zero memset.

"Translator output" suggests that translation is complete and we just have its output to link together. Optimization is "semantic analysis"; you cannot optimize without reasoning about meaning, and optimization also implies that translation is still going on: the output of earlier translation is still being tweaked, with regard to the meaning of the original source.

Re: How to zero a buffer

#165

Post by maxlybbert »

e12e wrote: post #152
maxlybbert wrote: post #126

Earlier quoted context omitted.

I was referring to the first sentence ("It is a little mind boggling that support for proper handling of this didn't arrive until c11."). I don't see anything C11-specific in the code Percival posted. I don't know enough to say anything useful about the rest of your comment.

My point was that this dance around "observed behaviour" isn't needed in C11, as per: "(...) on C11 (are there any fully C11-compliant platforms yet?) you can use the memset_s function. (...) [which is] guaranteed (or at least specified) to write the provided buffer and to not be optimized away." On another note, searching for memset_s and openbsd yielded this hit from 2012: https://mail-index.netbsd.org/tech-securit…

Thanks. I had missed the part in the article about the C11 changes.

Re: How to zero a buffer

#166

Post by dllthomas »

ovi256 wrote: post #132
sgentle wrote: post #129

This all seems kind of silly. Why doesn't C have a type qualifier like called "secure" to inform the compiler that it should avoid security-compromising optimisations and maybe even automatically zero the memory when it falls out of scope?

That sounds a lot like automatic memory management! To a C dev, that's the same as communism to a US Republican.

As a C dev, no. First, stack allocation is a type of "automatic memory management", and in most situations we C devs are perfectly comfortable with it. Second, in terms of how the memory is allocated/deallocated, the above doesn't sound any different than stack allocation. The difference is more like "volatile", telling the compiler "this memory is special, treat it carefully", and it mostly doesn't seem unreasonable. Note that C compilers frequently have extensions providing a way of naming destructors for particular variables. It probably would still be possible to skip it with a non-local jump (longjmp or computed goto) but avoiding those in security conscious code is probably already standard - it basically is in most code I've encountered.

Re: How to zero a buffer

#167

Post by legulere »

jhallenworld wrote: post #33

Slightly OT since it has little to do with security, but fighting the optimizer is something FPGA Verilog and VHDL designers must also master. If you don't use an the result of some logic it will be optimized out. One way to prevent this is to route it to a pin. If logic is fed by a constant, it will be optimized out right up to the point where the result of the logic is mixed with some external input. (early tools c…

Why would you want your FPGA to have circuits that aren't used? And why don't you want constant expressions to be pre-calculated by the optimizer?

Re: How to zero a buffer

#170

Post by syncsynchalt »

clarry wrote: post #142
ibisum wrote: post #118

Earlier quoted context omitted.

>Why would you want to zero a buffer ? Because it may contain sensitive information, I presume. You don't zero sensitive buffers. You randomize them, then free() them.

Why do you randomize them?

Because just free()ing them means anyone calling malloc() can get your password.
Post reply on HN