Full Disclosure mailing list archives
Re: Major gcc 4.1.1 and up security issue
From: <Glenn.Everhart () chase com>
Date: Mon, 22 Jan 2007 17:27:35 -0500
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 () lists grok org uk [mailto:full-disclosure-bounces () lists grok org uk]On Behalf Of Valdis.Kletnieks () vt edu Sent: Monday, January 22, 2007 2:50 PM To: Marcin Owsiany Cc: full-disclosure () lists 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/
Current thread:
- Re: Major gcc 4.1.1 and up security issue, (continued)
- Re: Major gcc 4.1.1 and up security issue Valdis . Kletnieks (Jan 16)
- Re: Major gcc 4.1.1 and up security issue Marcus Graf (Jan 17)
- Re: Major gcc 4.1.1 and up security issue Valdis . Kletnieks (Jan 17)
- Re: Major gcc 4.1.1 and up security issue Marcus Graf (Jan 17)
- Re: Major gcc 4.1.1 and up security issue Pavel Kankovsky (Jan 20)
- Re: Major gcc 4.1.1 and up security issue Marcin Owsiany (Jan 21)
- Re: Major gcc 4.1.1 and up security issue Valdis . Kletnieks (Jan 22)
- Re: Major gcc 4.1.1 and up security issue Marcin Owsiany (Jan 22)
- Re: Major gcc 4.1.1 and up security issue Valdis . Kletnieks (Jan 22)
- Re: Major gcc 4.1.1 and up security issue Marcin Owsiany (Jan 21)
- Re: Major gcc 4.1.1 and up security issue Valdis . Kletnieks (Jan 16)
- Message not available
- Re: Major gcc 4.1.1 and up security issue Michele Cicciotti (Jan 21)