How to zero a buffer • Hacker News Board

Re: How to zero a buffer

#11

Post by tiffanyh » Thu, Sep 04, 2014, 8:23 PM UTC

cperciva wrote: post #7

tiffanyh wrote: post #5

For those of you unaware, Colin Percival (author of the blog) was for many years the FreeBSD Security Officer and he's highly recognized in the field for his expertise. He also runs http://www.tarsnap.com/ which is arguably the most secure (and cost effective) back up solution in the market. (I'm in no way affiliated with Colin and/or Tarsnap. Just a fan of his work and humble attitude.)

humble attitude I'm guessing you haven't seen the "comeback of all time" thread...

I haven't.

But I think it's super funny and cool that you (yourself) are pointing it out.

All the best with you.

Edit: just read the "comeback of all time". That was really funny. Nice nod from PG as well. For those of you unaware like me: https://news.ycombinator.com/item?id=35083 Colin is our resident mathematical genius :)

Re: How to zero a buffer

#12

Post by [deleted] » Thu, Sep 04, 2014, 8:26 PM UTC

angersock wrote: post #2

This sort of thing would be exactly what should go into the "Friendly C" dialect being chatted about the other day--for things like zeroing memory, it's very unexpected that a compiler would be like "nah, not feeling it...nobody will notice anyways".

[deleted]

Re: How to zero a buffer

#13

Post by drivingmenuts » Thu, Sep 04, 2014, 8:27 PM UTC

Why would the compiler be allowed optimize away a call to a perfectly valid function? This seems like it's allowing to compiler to make judgement calls on whether or not your code is worthy of being executed.

Re: How to zero a buffer

#14

Post by adultSwim » Thu, Sep 04, 2014, 8:29 PM UTC

Someone1234 wrote: post #3

Can someone explain this line: static void * (* const volatile memset_ptr)(void *, int, size_t) = memset; I've written some C but that is utter gibberish to me.

http://ieng9.ucsd.edu/~cs30x/rt_lt.rule.html

Learning the right-left rule helps here. You'll still need to know what the keywords mean.

Re: How to zero a buffer

#15

Post by ars » Thu, Sep 04, 2014, 8:34 PM UTC

angersock wrote: post #2

This sort of thing would be exactly what should go into the "Friendly C" dialect being chatted about the other day--for things like zeroing memory, it's very unexpected that a compiler would be like "nah, not feeling it...nobody will notice anyways".

No, you are looking at it backward. The compiler tries to optimize the program so that it will run fast.

If you force it to execute this code it only benefits the very rare security program, yet every single program will run slower.

That's a bad tradeoff. Better to make the security program jump through hoops and let everyone else run fast.

Re: How to zero a buffer

#16

Post by tiffanyh » Thu, Sep 04, 2014, 8:34 PM UTC

cperciva wrote: post #7

tiffanyh wrote: post #5

For those of you unaware, Colin Percival (author of the blog) was for many years the FreeBSD Security Officer and he's highly recognized in the field for his expertise. He also runs http://www.tarsnap.com/ which is arguably the most secure (and cost effective) back up solution in the market. (I'm in no way affiliated with Colin and/or Tarsnap. Just a fan of his work and humble attitude.)

humble attitude I'm guessing you haven't seen the "comeback of all time" thread...

Colin, if you don't me asking (and this is extremely off topic), do you know of any resources to read up on the differences between FreeBSD and DragonflyBSD now 11 years after the split.

I'm not looking for you to take sides on the matter. I just enjoy reading history and would like to read a recent review of the two BSD now 11 years later and how they compare.

I've looked and looked for the past few months and can't seen to find a good solid length article on it ... which is why I ask.

Re: How to zero a buffer

#17

Post by dietrichepp » Thu, Sep 04, 2014, 8:37 PM UTC

drivingmenuts wrote: post #13

Why would the compiler be allowed optimize away a call to a perfectly valid function? This seems like it's allowing to compiler to make judgement calls on whether or not your code is worthy of being executed.

Because the C standard permits such optimizations. It is really just a case of inlining followed by dead store optimization, two fairly common optimization passes which are normally desired.

The subtlety is that while the compiler considers it a dead store, you don't, because you're going behind the compilers back to examine memory afterwards.

Re: How to zero a buffer

#18

Post by DSMan195276 » Thu, Sep 04, 2014, 8:41 PM UTC

drivingmenuts wrote: post #13

Why would the compiler be allowed optimize away a call to a perfectly valid function? This seems like it's allowing to compiler to make judgement calls on whether or not your code is worthy of being executed.

It's because memset is a standard function and has a defined standard way of acting, with the most important part being that it doesn't produce any side-effects. It's also worth noting that accessing memory that's no longer in the current scope is undefined-behavior, so the compiler can assume it doesn't happen. Thus the memset has absolutely zero effect on the actual program and isn't necessary.

In general this isn't a big deal. It's only a big deal here because we're working on the assumption that you might have an issue in your code that invokes undefined-behavior and access contents of memory that you're not supposed to be looking at anymore, and the compiler's just assuming that your program won't ever allow that.

Re: How to zero a buffer

#19

Post by JoshTriplett » Thu, Sep 04, 2014, 8:42 PM UTC

drivingmenuts wrote: post #13

Why would the compiler be allowed optimize away a call to a perfectly valid function? This seems like it's allowing to compiler to make judgement calls on whether or not your code is worthy of being executed.

The compiler constantly makes judgement calls on whether or not your code needs to run.

For instance:

    if (something)
        do_something();

Elsewhere:

    #ifdef CONFIG_RUNTIME_ENABLE_SOMETHING
    bool something = false;
    /* and some means of changing something at runtime */
    #else
    const bool something = false;
    #endif

If you don't define CONFIG_RUNTIME_ENABLE_SOMETHING, and thus "something" cannot change at runtime, then the compiler should recognize the if as always false and throw away the call to do_something(). If that was the only call to do_something(), it should throw away the code of do_something().

Re: How to zero a buffer

#20

Post by greglindahl » Thu, Sep 04, 2014, 8:43 PM UTC

drivingmenuts wrote: post #13

Why would the compiler be allowed optimize away a call to a perfectly valid function? This seems like it's allowing to compiler to make judgement calls on whether or not your code is worthy of being executed.

There's a lot of dead code in real programs, and this kind of optimization gets rid of a lot of it.