> I'm exactly talking about the semantics of "undefined" here. It would
> be immensely reassuring if a compiler would at least interpret this as
> "unspecified, but consistent". Even better would be a defined and
> documented semantics for everything left undefined by the standard.
Are you propo
> 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
On Sat, 2007-01-27 at 02:47 +0100, Andreas Bogk wrote:
> I'm exactly talking about the semantics of "undefined" here. It would
> be immensely reassuring if a compiler would at least interpret this as
> "unspecified, but consistent". Even better would be a defined and
> documented semantics for
Joe Buck wrote:
Those who are eager to have everything defined and repeatable should
choose a different programming language, say, Java. C and C++ don't
do what you want, and you're not going to convince the developers to
cripple the compiler the way you want no matter how much you post.
Good
Andreas Bogk <[EMAIL PROTECTED]> writes:
> Then maybe it shouldn't be the default in autoconf. But wasn't -O3 the
> set of optimizations considered potentially unsafe?
No. -O3 is a set of optimizations which are useful for many program
but which will cause a substantial number of programs to ru
On Sat, Jan 27, 2007 at 02:47:44AM +0100, Andreas Bogk wrote:
> I'm exactly talking about the semantics of "undefined" here. It would
> be immensely reassuring if a compiler would at least interpret this as
> "unspecified, but consistent". Even better would be a defined and
> documented semantics
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
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
> "Robert" == Robert Dewar <[EMAIL PROTECTED]> writes:
Robert> Note by the way that formally safety-critical or security-critical
Robert> software is very unlikely to be compiled at -O2 anyway.
I think it is more likely, on Linux at least, that software will be
compiled with whatever autoconf
On 1/26/07, Daniel Berlin <[EMAIL PROTECTED]> wrote:
>
> > 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 dis
Andreas Bogk wrote:
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
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
> 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.
Errr, actually, Seongbae
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
Andreas Bogk 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 always sa
On Fri, Jan 26, 2007 at 10:34:06PM +0100, Andreas Bogk 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 doe
On Jan 26, 2007, at 1:34 PM, Andreas Bogk wrote:
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 a
Andreas Bogk 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.
Anything other th
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
Robert Dewar wrote:
>> So basically you're saying gcc developers should compensate for other
>> people's sloppy engineering? ;-)
>
> Yes I would say! where possible this seems an excellent goal.
I agree: when it's possible to support non-standard legacy semantics
that do not conflict with the s
Dave Korn wrote:
You mean we should invoke the as-if rule in conjunction with the nasal
demons tradition and /actually/ erase the user's hard-drive at compile time if
they write a signed overflow? ;)
Well I already showed a case where assumptions of undefinedness could
lead to such a r
On 24 January 2007 12:51, Richard Kenner wrote:
>> Your conclusion may well be correct. The question for this group is:
>> what's the best that GCC can do to serve the community/society?
>
> Do all it can to discourage people from writing safety- or
> security-critical code in a language they do
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
Richard Kenner wrote:
You're misrepresenting the argument here. This is not just about newly
written software, but also about software that already has been written.
There are multiple arguments here. That comment of mine was addressing the
claim that somebody (I think you) made that stated t
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
Steven Bosscher wrote:
On 1/25/07, Andreas Bogk <[EMAIL PROTECTED]> 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? ;-)
Ye
> You're misrepresenting the argument here. This is not just about newly
> written software, but also about software that already has been written.
There are multiple arguments here. That comment of mine was addressing the
claim that somebody (I think you) made that stated that it was too much t
On 1/25/07, Andreas Bogk <[EMAIL PROTECTED]> 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? ;-)
Gr.
Steven
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
Richard Kenner wrote:
Oh, and teaching all of the programmers out there all the subtle nuances
of C and trying to get them to write proper code: good luck. That
simply won't happen.
If people who write security-critical code in a programming language
can't take time to learn the details of tha
The one security related argument that makes sense to me
here is the business of writing tests for overflow that
make the wrap assumption. I can see that having a security
implication.
> Suddenly rejecting all that code, or making it generate a different
> result, would not serve the community/society.
Sure, but that wasn't the issue I was addressing.
I was addressing the claim that we allegedly have people writing security-
and/or safety-critical software who don't understand
On Wed, Jan 24, 2007 at 07:51:21AM -0500, Richard Kenner wrote:
> > Your conclusion may well be correct. The question for this group is:
> > what's the best that GCC can do to serve the community/society?
>
> Do all it can to discourage people from writing safety- or
> security-critical code in a
> Your conclusion may well be correct. The question for this group is:
> what's the best that GCC can do to serve the community/society?
Do all it can to discourage people from writing safety- or
security-critical code in a language they don't understand? ;-)
Richard Kenner wrote:
>> Oh, and teaching all of the programmers out there all the subtle nuances
>> of C and trying to get them to write proper code: good luck. That
>> simply won't happen.
>
> If people who write security-critical code in a programming language
> can't take time to learn the de
> Oh, and teaching all of the programmers out there all the subtle nuances
> of C and trying to get them to write proper code: good luck. That
> simply won't happen.
If people who write security-critical code in a programming language
can't take time to learn the details of that language relevant
> Yes, absolutely. There is a difference between well-defined and
> understood semantics on one hand, and undefined and probably dangerous
> behaviour on the other hand. It's the difference between security
> audits of C software being hard and completely hopeless.
I disagree. Code written with
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
Ian Lance Taylor wrote:
> Andreas Bogk <[EMAIL PROTECTED]> writes:
> I think a better way to describe your argument is that the compiler
> can remove a redundant test which would otherwise be part of a defense
> in depth. That is true. The thing is, most people want the compiler
> to remove redu
* Joe Buck:
> 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 co
Andreas Bogk <[EMAIL PROTECTED]> writes:
> > Making it defined and wrapping doesn't help at all. It just means you
> > write different checks, not less of them.
>
> You have just seen somebody who can be considered an expert in matters
> of writing C sofware come up with a check that looks correc
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
> This is a typical example of removing an if branch because signed
> overflow is undefined. This kind of code is common enough.
I could not have made my point any better myself.
And you think that somehow defining it (which the definition people
seem to favor would be to make it wrapping) am
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
Andreas Bogk <[EMAIL PROTECTED]> writes:
> The case is clear when an if branch is folded away, because some
> comparison is folded that would not have been under twos-complement
> semantics. This is a pattern that probably doesn't happen all that much
> in code out there, except in post-facto ove
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
On Mon, Jan 22, 2007 at 06:48:16PM -0500, Andreas Bogk wrote:
> 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 a
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
On Mon, Jan 22, 2007 at 11:16:06AM -0800, Ian Lance Taylor wrote:
> The new -Wstrict-overflow
> warning will issue warnings for each case where gcc assumes that
> signed overflow is undefined.
>
> To be clear, this -Wstrict-overflow option generates a lot of false
> positives. That is becau
Andreas Bogk <[EMAIL PROTECTED]> writes:
> It is my fear that the existing behaviour of gcc when used without
> -fwrapv breaks a lot of code out there that was written with the
> implicit assumption that signed ints would overflow the way the
> underlying machine integers do. More importantly, so
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
51 matches
Mail list logo
