lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 09 Oct 2015 03:04:08 +0300 From: Alexander Cherepanov <ch3root@...nwall.com> To: discussions@...sword-hashing.net Subject: Re: [PHC] Specification of a modular crypt format (2) On 2015-10-06 07:19, Peter Gutmann wrote: > Alexander Cherepanov <ch3root@...nwall.com> writes: > >> Hence a compiler is free to assume that this case is impossible (i.e. >> that "value <= INT_MAX / 10") and to use this knowledge to optimize the >> code in the program after this expression and even before it. > > Fair enough. I was assuming the compiler would see that valTmp wasn't live > until after the value range check, so would move the code down to where it > was used before working with it. The second link you provided (thanks, very It's a mandatory link in any discussion about UB:-) Usually right after a link to Regehr: http://blog.regehr.org/archives/213 > interesting, I'd seen other discussions on this but not that one) is kinda > scary, particularly the Dead Code Elimination vs. Redundant Null Check > Elimination race condition. > >> This has (almost) nothing to do with unsigned numbers. > > Ah, OK, I was assuming it was a side-effect of moving things between > different types... > >> Both gcc 4.9 -O2 and clang 3.5 -O1 produce binaries which print a >> negative number. > > Ouch! > >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475 > > Ugh, that matches other threads I've seen involving the gcc developers, > they'll argue till they're blue in the face that having gcc break code is > valid because if you squint at the spec just right then the behaviour isn't > explicitly disallowed, but won't lift a finger to do the right thing. > > Maybe I should just tell everyone to use icc, which doesn't seem to have > these problems (and generally produces better code than gcc to boot). Or > Visual Studio, for which I still need to check what it does when I get to > a Windows box with it installed. Maybe just fix bugs in the code?:-) Seriously, some recent tools make it easier. First of all, run your test suite with valgrind, Address Sanitizer and Undefined Behavior Sanitizer. Raise code coverage with a fuzzer (e.g. American Fuzzy Lop) and, perhaps, KLEE. Look which other sanitizers[1][2] are relevant to your project. You can even check enum use and unsigned integer overflows (even though it's well-defined in C). [1] https://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html#index-fsanitize_003daddress-676 [2] http://clang.llvm.org/docs/UsersManual.html#controlling-code-generation Then use tools like Clang Static Analyzer and cppcheck. Then proceed to STACK[3], Frama-C etc. [3] https://css.csail.mit.edu/stack/ For legacy code, until things could be fixed for real, disable all optimizations or just start with the usual suspects: -fwrapv or -fno-strict-overflow, -fno-delete-null-pointer-checks, -fno-strict-aliasing. -- Alexander Cherepanov
Powered by blists - more mailing lists