Date: Mon, 22 Jan 2007 17:27:35 -0500
From: <Glenn.Everhart@...se.com>
To: <Valdis.Kletnieks@...edu>, <marcin@...iany.pl>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: Major gcc 4.1.1 and up security issue

Actually some of the older machines (pdp11 in particular) with their
signed and unsigned conditional branches forced you to think about
overflow, and if your programs happened to run in memory above 32K bytes
(16K words) things were too apt to just crash if you got that stuff wrong.

I recall though that condition codes (the pdp11 approach to capturing overflows
and the like) were said to be a feature that makes it very hard to speed a processor
up. BTW things got still more interesting on 12 bit boxes. In that era there were
few of the constructs later CPUs like Z80 got to support wider operations; you did
it all the hard way.
I suspect those who recall using the older boxes may have less trouble with integer
overflow than folks who have not (who in a few years may be recalling when an overflow
occurred at "only" 2 billion. At some point, maybe in a 64 or 128 bit word, it may be
feasible to just routinely zap the high part of a register to be sure you never get the
wrong sign, sight unseen...
Glenn Everhart


-----Original Message-----
From: full-disclosure-bounces@...ts.grok.org.uk
[mailto:full-disclosure-bounces@...ts.grok.org.uk]On Behalf Of
Valdis.Kletnieks@...edu
Sent: Monday, January 22, 2007 2:50 PM
To: Marcin Owsiany
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: [Full-disclosure] Major gcc 4.1.1 and up security issue


On Sun, 21 Jan 2007 12:07:18 GMT, Marcin Owsiany said:

> I also think that CPUs can detect internally when an overflow happens -
> is there a way to use that feature in C somehow, in a portable way?
> (Somehow I feel that the answer is that not all CPUs do that, so - no.)

The fact that some CPUs implement overflow detection in ways best described
as byzantine and sometimes merely flawed or lacking entirely is why C does
such hand-waving on the issue.  It's generally considered performance-crippling
to add inline code that does a "test condition/branch" pair after *every single*
opcode that might cause an overflow - so the C paradigm is to leave them out
and have the programmer code tests when actually needed.

You think it's bad *now*, where you have to force-feed a 2-billion-something
value in to cause an integer overflow, you obviously aren't old enough to have
programmed on 16-bit machines, where numbers around 32,000 were sufficient,
and even 'unsigned int' didn't suffice to let you sort 5-digit US postal ZIP
codes...

(And we won't mention the horrorshow that was floating point before IEEE-standard
became widely used...)


**********************************************************************
This transmission may contain information that is privileged, confidential, legally privileged, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you.
**********************************************************************

_______________________________________________
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