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: US-CERT Vulnerability Note VU#162289


* Robert Dewar:

> Florian Weimer wrote:
>> * Robert C. Seacord:
>>
>>> i agree that the optimization is allowed by C99.  i think this is a
>>> quality of implementation issue,  and that it would be preferable for
>>> gcc to emphasize security over performance, as might be expected.
>>
>> I don't think this is reasonable.  If you use GCC and its C frontend,
>> you want performance, not security.
>
> I find this a *VERY* dubious claim, in my experience VERY few users
> are at the boundary where small factors in performance are critical,
> but MANY users are definitely concerned with security.

Existing safe C implementations take a performance hit which is a factor
between 5 and 11 in terms of execution time.  There is some new research
that seems to get away with a factor less than 2, but it's pretty recent
and I'm not sure if it's been reproduced independently.  If GCC users
are actually willing to take that hit for some gain in security
(significant gains for a lot of legacy code, of course), then most of
the recent work on GCC has been wasted.  I don't think this is the case.

Keep in mind it's not the comparison that's the real problem here, it's
the subsequent buffer overflow.  And plugging that hole in full
generality is either difficult to do, or involves a significant run-time
performance overhead (or both).

> To me, dubious optimizations like this at the very least should
> be optional and able to be turned off.

Why is this optimization dubious?  We would need to look at real-world
code to tell, and so far, we haven't heard anything about the context in
which the issue was originally encountered.


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