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  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]
Date: Fri, 09 Oct 2015 03:04:08 +0300
From: Alexander Cherepanov <>
Subject: Re: [PHC] Specification of a modular crypt format (2)

On 2015-10-06 07:19, Peter Gutmann wrote:
> Alexander Cherepanov <> 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:

> 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!
> 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).


Then use tools like Clang Static Analyzer and cppcheck. Then proceed to 
STACK[3], Frama-C etc.


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,

Alexander Cherepanov

Powered by blists - more mailing lists