Re: Signed int overflow behaviour in the security context

2007-01-26 Thread Andreas Bogk
Robert Dewar wrote: >> I don't see why that demand would prevent register allocation. Maybe >> you can explain that to me. > Probably the best thing is to refer you to a good compiler book, such > as the dragon book. It really is necessary to understand compiler > technology to understand this kin

Re: Signed int overflow behaviour in the security context

2007-01-26 Thread Andreas Bogk
Seongbae Park wrote: >> Seongbae, didn't you say that Sun's compiler uses the fact that signed >> overflow is undefined when performing optimizations? > Correct. I stand corrected. I didn't read the fine print in http://docs.sun.com/source/806-3568/ncg_compliance.html that said "unless you us

Re: Signed int overflow behaviour in the security context

2007-01-26 Thread Andreas Bogk
Robert Dewar wrote: >> Making a call here before knowing this is not sensible. In fact, >> I'm tempted to argue that it is generally a bad idea to do >> optimizations that lead to the same expression being evaluated to >> different results without making the user explicitly request them. > People

Re: Signed int overflow behaviour in the security context

2007-01-26 Thread Andreas Bogk
Joe Buck wrote: >> But if the gcc user base prefers performance over security, and you are >> willing to go with them, they might get what they deserve. > You continue to confidently assert, without any backup, that loop > unrolling that assumes overflow does not occur has a negative security > imp

Re: Signed int overflow behaviour in the security context

2007-01-26 Thread Andreas Bogk
Mark Mitchell wrote: > In this specific case, we know there is a significant performance > impact, and we know that performance is very important to both the > existing and potential GCC user base, so I think that making the > compiler more aggressive at -O2 is sensible. Whether or not that is sen

Re: Signed int overflow behaviour in the security context

2007-01-25 Thread Andreas Bogk
Richard Kenner wrote: > I agree with all the arguments about legacy code, but I'm much less > tolerant of such arguments for NEW code. Thanks for clarification. I think legacy code is the big problem here anyways. Andreas

Re: Signed int overflow behaviour in the security context

2007-01-25 Thread Andreas Bogk
Steven Bosscher wrote: >> "It's not my fault if people write buggy software" is a lame excuse >> for sloppy engineering on the part of gcc. > So basically you're saying gcc developers should compensate for other > people's sloppy engineering? ;-) This might be a little exaggerated, but there's ce

Re: Signed int overflow behaviour in the security context

2007-01-25 Thread Andreas Bogk
Richard Kenner wrote: > I was addressing the claim that we allegedly have people writing security- > and/or safety-critical software who don't understand the semantics of that > language as they relate to safety and security (namely, what overflows do). > That's a serious problem. Of course, there

Re: Signed int overflow behaviour in the security context

2007-01-23 Thread Andreas Bogk
Ian Lance Taylor wrote: >> You have just seen somebody who can be considered an expert in >> matters of writing C sofware come up with a check that looks >> correct, but is broken under current gcc semantics. That should >> make you think. > I'm not entirely unsympathetic to your arguments, but

Re: Signed int overflow behaviour in the security context

2007-01-23 Thread Andreas Bogk
Daniel Berlin wrote: > And you think that somehow defining it (which the definition people > seem to favor would be to make it wrapping) ameliorates any of these > concerns? Yes, absolutely. There is a difference between well-defined and understood semantics on one hand, and undefined and probabl

Re: Signed int overflow behaviour in the security context

2007-01-23 Thread Andreas Bogk
Ian Lance Taylor wrote: > Consider code along these lines: > > struct s { int len; char* p; }; > > inline char > bar (struct s *sp, int n) > { > if (n < 0) > abort (); > if (n > sp->len) > abort (); > return sp->p[n]; > } > > void > foo (struct s *sp, int n) > { > int len = sp->l

Re: Signed int overflow behaviour in the security context

2007-01-22 Thread Andreas Bogk
Joe Buck wrote: > You appear to mistakenly believe that wrapping around on overflow is a > more secure option. It might be, but it usually is not. There are many > CERT security flaws involving integer overflow; the fact that they are > security bugs has nothing to do with the way gcc generates c

Re: Signed int overflow behaviour in the security context

2007-01-22 Thread Andreas Bogk
Ian Lance Taylor wrote: > I just want to report that I have a working patch to generate warnings > every time gcc modifies code relying on the fact that signed overflow > is undefined, except for cases where signed loop indexes are assumed > to not wrap around. I plan to start submitting this patc

Signed int overflow behaviour in the security context

2007-01-22 Thread Andreas Bogk
Dear compiler hackers, I feel compelled to revisit a topic that has already been extensively discussed on this mailing list, unfortunately with an outcome that is highly dangerous to the security of about any existing system compiled with gcc in the world. It is my fear that the existing behaviou