phc-discussions - Re: [PHC] Specification of a modular crypt format (2)

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

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <56170478.8020008@openwall.com>
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