3 ms·
Because it's far from being thirty seconds (as seen in the post by ploxiln here): http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1967.htm http://www.open-std
by acqq 7y ago
Because it's far from being thirty seconds (as seen in the post by ploxiln here):
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1967.htm http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1967.htm
The most interesting quote regarding these "safer" interfaces from the report:
"The design of the Bounds checking interfaces, though well-intentioned, suffers from far too many problems to correct. Using the APIs has been seen to lead to worse quality, less secure software than relying on established approaches or modern technologies. ... Therefore, we propose that Annex K be either removed from the next revision of the C standard, or deprecated and then removed."
- mikeash 7y agoI don’t understand. Your link is talking about the difficulty of using these functions. But here, the functions are already being used. What’s missing is implementations of them. They chose to implement these functions without the security checks, but implementing them with the security checks is not hard.
- userbinator 7y agoThat whole article is basically saying that those extra checks are useless anyway in correctly written code, as otherwise it would be code that can be tested and reached: On the other hand, in code that does check for and attempts to handle errors reported by the APIs, the new error handling paths tend to be poorly tested (if at all) because the runtime-constraint violation can typically be triggered only once, the first time it is found and before it's fixed. After the flaw is removed, the handling code can no longer be tested and, as the code evolves, can become a source of defects in the program.
- microtherion 7y agoIt's possible that they are calling the functions, but passing incorrect length arguments so frequently that they are best ignored.
- zrm 7y ago> Therefore, we propose that Annex K be either removed from the next revision of the C standard, or deprecated and then removed. This irked me, because along with useless junk like memcpy_s, Annex K had memset_s, which in particular (and unlike memset(3)) was guaranteed not to be optimized out by the compiler. Meanwhile Spectre has made it more important than ever for programs to clear any sensitive data out of memory as soon as it's no longer needed, so we actually need that. And it's troublesome to either have half a dozen ifdefs for all the different platform-specific functions that do the same thing, with as many possibilities to call one of them wrong, or have to pick up a dependency on a crypto library just to get e.g. sodium_memzero().
- rurban 7y agoNot arguing with your useless junk attitude. Useless junk is the glibc and its FORTIFY_SOURCE "maybe we catch it or maybe not" attempt. But sodium_memzero() is not safer than memset_s. If only provides a compiler barrier, but no memory barrier. AFAIK only my safeclib memset_s is "safe", but I don't provide a clflush there. Maybe I should.
- zrm 7y agoAll the more reason there should be a function in the C standard that does it properly and uniformly across platforms.