This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Signed int overflow behaviour in the security context


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 sensible depends on the outcome of running
-Wstrict-overflow over some code, to get an idea of how pervasive the
use of post-overflow checking or other vulnerabilities based on the
undefinedness of signed integer overflow really is.

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.

But if the gcc user base prefers performance over security, and you are
willing to go with them, they might get what they deserve.  Microsoft
has suffered from security problems for so long that they have put an
immense effort into Vista to fix it.  I'm not saying it will be
bug-free, but it will be significantly harder to actually find an
exploitable bug in it.  Windows got all of the attention from the bad
guys for sheer number of installed systems so far, not because Linux is
inherently more secure.  But if Vista turns out to be infeasible to
attack, their attention will wander to the next promising target.  And
that will be Linux and the BSDs (including the one with the apple).

> And, Ian is working on -fno-strict-overflow, so that users have a
> choice, which is also very sensible.  Perhaps the distribution vendors
> will then add value by selectively compiling packages that need it with
> -fno-strict-overflow so that security-critical packages are that much
> less likely to do bad things, while making the rest of the system go
> faster by not using the option.

Again, what exactly do you think is a "security-critical package"?  In
my eyes, any program that ever touches external data, be it from the
network or reading some file, or any library that links against such a
program is relevant to security, in that a bug in it might be used to
launch an attack.  This translates into pretty much everything in a
distribution, so much that -fstrict-overflow should be the exception,
not the norm.

I'm curious to see what the vendors will be doing.

> I think we've selected a very reasonable path here.

I don't agree, unless you have a "performance is more important than
security" policy.  In that case, however, I will go looking for another
C compiler.

Andreas


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]