3 ms·

If you're modifying memory immediately before freeing it (i.e. after the last time you read it), don't you have to be extra super careful to do so in a way that

If you're modifying memory immediately before freeing it (i.e. after the last time you read it), don't you have to be extra super careful to do so in a way that the compiler won't optimize the operation into nothingness? (I don't program in compiled languages very much, so I don't know the details about this.)

kayamon 11y ago
Actually yeah, that's a very good point. Sometimes compilers are just too clever. I think some systems have a "secure memset" function that can be used for things like this - i.e. one that's guaranteed not to be optimized out.
- ape4 11y ago
  Yes, memset_s(). Which makes me think there should be a free_s().
  - TheLoneWolfling 11y ago
    memset_s, or a mythical free_s, is not enough. The compiler can, and will, make copies of data behind the scenes. And not erase said copies. What we really need is a keyword / modifier that says that when X passes out of scope no state related to X may be leaked. Ideally, that can be applied to a function / block as well as a variable. (Or rather, not necessarily no state. Read "as little state as possible", preferably with modifiers that panic unless the compiler can ensure specific things.)
    - mpu 11y ago
      The C standard works at an abstraction level that makes it unsuitable for security applications, I would advocate for a new language here. It needs serious PL research with informarion flow reasoning, what we need is just a new kind of language much more machine aware (yes, more low-level) than C.
      - TheLoneWolfling 11y ago
        Agreed on some level. On the other hand, something as simple as a keyword marking a variable as "as secure as possible given hardware constraints (read: should wipe any temporary copies and the variable itself after it goes out of scope, should attempt to prevent it from being written to non-volatile storage, that sort of thing)" (sort of like how inline works), with compilers required to bail if the constraint cannot be done to the level specified, would be a massive step in the right direction.
thaumaturgy 11y ago
Yes, you're correct. See e.g.: http://www.eliteraspberries.com/blog/2012/10/zero-and-forget--caveats-of-zeroing-memory-in-c.html http://www.eliteraspberries.com/blog/2012/10/zero-and-forget... (which has a link to some HN discussion at the end of the article).
TheLoneWolfling 11y ago
Yes. There is, quite literally, no way to ensure data is not leaked (namely, that data is zeroed / etc) in portable C / C++.
- alain94040 11y ago
  Or in assembly, for that matter. You never what data the CPU is duplicating behind your back: store buffers, prediction, etc.
  - TheLoneWolfling 11y ago
    At least with assembly most of the time you can't ever get that data back. Although not always. With C it's far too easy to get the data back. Also, you missed the worst example: CPU cache.

kayamon 11y ago

Actually yeah, that's a very good point. Sometimes compilers are just too clever. I think some systems have a "secure memset" function that can be used for things like this - i.e. one that's guaranteed not to be optimized out.

ape4 11y ago
Yes, memset_s(). Which makes me think there should be a free_s().
- TheLoneWolfling 11y ago
  memset_s, or a mythical free_s, is not enough. The compiler can, and will, make copies of data behind the scenes. And not erase said copies. What we really need is a keyword / modifier that says that when X passes out of scope no state related to X may be leaked. Ideally, that can be applied to a function / block as well as a variable. (Or rather, not necessarily no state. Read "as little state as possible", preferably with modifiers that panic unless the compiler can ensure specific things.)
  - mpu 11y ago
    The C standard works at an abstraction level that makes it unsuitable for security applications, I would advocate for a new language here. It needs serious PL research with informarion flow reasoning, what we need is just a new kind of language much more machine aware (yes, more low-level) than C.
    - TheLoneWolfling 11y ago
      Agreed on some level. On the other hand, something as simple as a keyword marking a variable as "as secure as possible given hardware constraints (read: should wipe any temporary copies and the variable itself after it goes out of scope, should attempt to prevent it from being written to non-volatile storage, that sort of thing)" (sort of like how inline works), with compilers required to bail if the constraint cannot be done to the level specified, would be a massive step in the right direction.

thaumaturgy 11y ago

Yes, you're correct. See e.g.: http://www.eliteraspberries.com/blog/2012/10/zero-and-forget--caveats-of-zeroing-memory-in-c.html http://www.eliteraspberries.com/blog/2012/10/zero-and-forget... (which has a link to some HN discussion at the end of the article).

TheLoneWolfling 11y ago

Yes. There is, quite literally, no way to ensure data is not leaked (namely, that data is zeroed / etc) in portable C / C++.

alain94040 11y ago
Or in assembly, for that matter. You never what data the CPU is duplicating behind your back: store buffers, prediction, etc.
- TheLoneWolfling 11y ago
  At least with assembly most of the time you can't ever get that data back. Although not always. With C it's far too easy to get the data back. Also, you missed the worst example: CPU cache.