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 > impact.
So far, I have only made this claim for the case of if branches being folded away, and from that extrapolated my demand to make all signed int overflow behaviour LIA-1 compliant. I have never explicitly talked about loop unrolling so far. But I'm interested in having a look at this case. Could you explain why depending on the undefinedness of overflow is necessary to do loop unrolling? If possible, show an example. I'll see whether I can construct something evil out of it. If we can establish beyond reasonable doubt that nothing bad can happen, loop unrolling could be treated specially. On the other hand, I'm curious to know as well what gcc does for loop unrolling in the case of unsigned integers. Also, it seems to me that the safe thing to do would be to only do loop unrolling in cases where value range propagation can establish that no overflow will happen. It might even be useful to provide a warning to the user in cases the compiler can't do that, because that usually indicates a programmer mistake. > The problem is, if an int overflow occurs and it wraps according > to LIA-1 semantics, that, also, is likely to have a security impact if the > program's author was not thinking about overflow. While there are programmers out there where any attempt at getting them to write even remotely secure software, most of them can be taught the concept of LIA-1 semantics, and a lot of them already know and write software accordingly. Getting them to understand that an expression like "if (a + b < a)" doesn't do what they would expect is harder. Getting them to understand that "if (a < 0)" might fail on them in obscure cases is close to impossible. > Every leading C compiler has for years done things like this to boost > performance on scientific codes. The Sun cc is a counter-example. And even then, authors of scientific code usually do read the compiler manual, and will discover any additional optimizer flags. > It seems clear that if value range propagation were to assume everywhere > that int overflow does not occur, then this would have bad effects on > existing code bases. No shipping GCC does this, and I doubt that one ever > will by default. There is a comment in make_range() that indicates the opposite. I can't read gcc code sufficiently well to figure out whether that is actually the case, though. Andreas
