4 ms·

I'm confused, why didn't they just mandate memset_s instead of introducing memset_explicit?

• Aissen 4y ago
  My understanding, following the reading of https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2897.htm https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2897.htm is that it was simpler to "salvage" a single function from "Annex K" by renaming it, considering that "Annex K" was both optional and controversial (some called to remove it).
• loeg 4y ago
  Because Annex K sucks and should be removed entirely.
  • mst 4y ago
    For those, like me, who weren't up to speed with why this argument is made, https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1967.htm https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1967.htm seems to be a good summary of the problems with it. (if it isn't, hopefully somebody who knows more will post a better link)
• rurban 4y ago
  Because people don't care abut security (or they just have no idea), hence they roll their own _FORTIFY_SOURCE hacks, but they still don't get memset_s right. So they rather named it what it is, protect from compiler optimizations, but not from cache side-channel attacks, which the _s variant would do. Because that is the secure variant. memset_explicit is just to overcome stubborn optimizer people who insist to optimize functions away (without warnings!), even when they have no idea about side-effects.
  • dataflow 4y ago
    > but not from cache side-channel attacks, which the _s variant would do Wow, was that a requirement for memset_s? I'd never heard of timing being a something guaranteed by the *_s functions, regardless of security being in their name.
    • rurban 4y ago
      When the ISO standard Annex K was written, they didn't know of those security problems yet. No one knew. But it is documented to be the secure variant, so known vulns need to be fixed there. It can be slow, it just needs to be secure.