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

201–210 of 216 posts

Re: How to zero a buffer

#201

Post by clarry »

api wrote: post #187

If your goal is just to "burn" the memory, why not write your own loop that copies some arbitrary piece of data that the compiler can't optimize out over the memory's contents? Do something like fill the buffer with its own pointer address.

It's been stated here already. You can write whatever you want into it. It doesn't matter. What matters is that the compiler realizes there's a dead store going into it, i.e. that the data is thrown away after it's written. So it can optimize out any write, since no conforming program can read that data after it's thrown away.

Re: How to zero a buffer

#204

Post by bunderbunder »

pcwalton wrote: post #117
bunderbunder wrote: post #102

Earlier quoted context omitted.

Yes. But dead store elimination combined with being allowed to dereference arbitrary pointers and leaving newly allocated blocks of memory uninitialized is problematic. Contrary to what the C standard would like us to believe, those other features do mean that dead store elimination alters the semantics of a program. It doesn't impact the semantics of the procedure whose dead stores are being eliminated, but it alter…

If your compiler couldn't perform dead store elimination on memory (remember, memory includes allocas), then you'd lose most of the benefits of performing standard SSA form optimizations after SROA has happened. Essentially you'd kill scalar replacement of aggregates, which is a critical optimization. It's very important for performance that it allowed to happen.

Note that I'm not saying that dead store elimination is the problem. I'm saying that dead store elimination in combination with other language features is a problem. Dead store elimination is not unique to C. But those other language features are. Since I'm complaining about C in particular, I submit that the bit that I'm most worried about isn't the stuff that every language does.

That said, I realize that allowing data that's hypothetically disappeared forever into the free() black hole to come back into the universe through white holes such as malloc() and buf[buf_length] aren't the only reasons why you'd want to make for sure that you can clear out unused memory. Which is why it would be nice if the C spec also included some way to securely clear up memory that the compiler isn't allowed to defeat. No, an optional feature in a spec that's only 3 years old and mostly not supported isn't good enough. If it isn't ubiquitous it's not a whole lot more useful than any of the platform- and architecture-specific fixes that already exist.

Re: How to zero a buffer

#205

Post by schoen »

dllthomas wrote: post #192
schoen wrote: post #178

Earlier quoted context omitted.

I think I heard of a timing attack that was introduced by CPU optimizations, not in the underlying code at all! But I can't remember what research that was and maybe I'm confusing two different issues.

Certainly plausible. If the CPU optimizes one path but not another, in principle that's some information. In practice, gathering enough data to get that above the noise floor and turning it into something useful besides would certainly be difficult but maybe not too difficult.

I might be thinking of some of the cache timing issues about sharing physical hardware with other guest VMs. There were papers in the last two years showing circumstances in which another VM on the same device can learn about secrets in caches via timing experiments. But that's a cache issue rather than a general pipeline issue. So I still can't remember if there's something else that I'm thinking of or if I'm just confusing it with the cache stuff.

http://blog.cryptographyengineering.com/2012/10/attack-of-we...

More recent stuff in this vein:

https://eprint.iacr.org/2014/435.pdf

(Yikes!)

Re: How to zero a buffer

#206

Post by TheLoneWolfling »

schoen wrote: post #178
dllthomas wrote: post #110

Earlier quoted context omitted.

"There's basically only one (or a family of) languages that have no optimisation at all" ... sort of. Chips themselves perform some optimizations.

I think I heard of a timing attack that was introduced by CPU optimizations, not in the underlying code at all! But I can't remember what research that was and maybe I'm confusing two different issues.

Well, the most obvious form of that is cache.

There's a entire class of timing attacks that rely on the CPU cache - they would not exist if CPUs didn't do the optimization of storing local copies of limited sections of RAM.

Re: How to zero a buffer

#207

Post by TheLoneWolfling »

exDM69 wrote: post #177
pjungwir wrote: post #173

Does anyone have any advice on articles about C compiler optimizations in general (especially gcc)? I'm doing my first serious C work in ten years, and I keep wondering if I should fuss with things like this or let the compiler handle it all: foo->bar->baz[i].oof = foo->bar->baz[i].durb + meep; vs what *tmp = foo->bar->baz[i]; tmp->oof = tmp->durb + meep; EDIT: I'm not asking for a link to this: https://gcc.gnu.org/o…

foo->bar->baz[i].oof = foo->bar->baz[i].durb + meep; This is fine, no need to "optimize" anything. This kind of common subexpression elimination should be done by any modern compiler (for any language!) and the algorithm behind it is taught in university classes too. Most of the time it's safe to use -O3. If you're doing numerical code with floating points -ffast-math is also pretty safe if your code is correct (ie.…

This shouldn't need to be said, but don't use -ffast-math if you want reproducibility. Unfortunately, the times when you most want reproducibility tend to be the same sorts of number-crunching where -ffast-math would be most useful.

Re: How to zero a buffer

#208

Post by DenisM »

kazinator wrote: post #101
DenisM wrote: post #85

Earlier quoted context omitted.

>In the absence of a stunningly advanced global optimization that peeks into other previously compiled units You'll be surprised, but this stuff exists since late last century, known as Link-Time Code Generation (LTCG): http://msdn.microsoft.com/en-us/magazine/cc301698.aspx

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…

When it's a choice between standards and a 10% performance gain, the latter will win.

Re: How to zero a buffer

#210

Post by dllthomas »

MichaelMoser123 wrote: post #209

You can have a function that wrapps memset with zero argument this wrapper should be in a different shared library, this way the compiler will not follow it; wait, that's exactly what memset_s is,

Not exactly. There's no reason memset_s can't be understood by the compiler, inlined, and optimized, so long as those bits still get zeroed. That's not the case for any of the other approaches.
Post reply on HN