4 ms·

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 thi

• 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.