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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <72514.1297391577@localhost>
Date: Thu, 10 Feb 2011 21:32:57 -0500
From: Valdis.Kletnieks@...edu
To: literalka@...a.eu
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: [Fwd: Re: {Java,PHP} Server Exploits]

On Thu, 10 Feb 2011 11:39:57 EST, Leon Kaiser said:

> "Yay open source"?
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

>>From comment #2 on that bug:

State-Changed-Why: See any faq on numerical analysis that mentions the x86.
    You are seeing the results of excess precision in the FPU.
    Either change the rounding precision in the FPCR, or work
    around the problem with -ffloat-store.

Let's look at the problematic line in the sample code:

    if (y != y2) printf("error\n");

This will cause the printf to trigger if the two numbers are bitwise identical
down to the last bit.  If y and y2 were computed via different code paths, and
thus hit different patterns of rounding and truncation, they could easily be
different in the last bit or two (for example, 3.993428883437 and
3.993428883436).  It's been well understood since literally the 1950s that if
you're trying to do any serious floating-point computation, such comparisons
should usually be written as 'if (abs(y - y2) < epsilon)' for whatever value of
epsilon you're willing to accept as a fuzz factor.

Although it's probably possible to "fix" gcc to do the right thing for the test
case in the bug report, it's in general *not* possible to "fix" this in the
general case.  It just becomes a total mess of little special corner cases and
makes performance of both the optimizer and the generated code totally tank.

There's only a limited amount of things the compiler and optimizer can do to save
a programmer from improper numeric analysis.

For further details, read comment 109 and/or the paper referenced in
comment 96.  Many of the other comments are also relevant.


Content of type "application/pgp-signature" skipped

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ