[SC-L] GCC and pointer overflows [LWN.net]

[Epstein, Jeremy]

Ken, a good example.  For those of you who want to reach much further
back, Paul Karger told me of a similar problem in the compiler (I don't
remember the language) used for compiling the A1 VAX VMM kernel, that
optimized out a check in the Mandatory Access Control enforcement, which
separates information of different classifications (*).  [For those not
familiar with it, this was a provably secure kernel on which you could
host multiple untrusted operating systems.  Despite what some young-uns
seem to think, VMs are not a new concept - they go back at least three
decades that I know of, and possibly longer.  The A1 VAX effort ended
roughly 20-25 years ago, to give a timeframe for this particular
compiler issue.]

--Jeremy

(*) At least that's what my memory tells me - if Paul is on this list,
perhaps he can verify or correct.

> -----Original Message-----
> From: sc-l-bounces at securecoding.org 
> [mailto:sc-l-bounces at securecoding.org] On Behalf Of Kenneth Van Wyk
> Sent: Thursday, May 01, 2008 9:14 AM
> To: Secure Coding
> Subject: [SC-L] GCC and pointer overflows [LWN.net]
> 
> FYI, here's an interesting article (and follow-on 
> discussions) about a recent bug in the GCC compiler collection.
> 
> http://lwn.net/Articles/278137/
> 
> The bug, which has been documented in a CERT advisory, 
> affects C code in which, under some circumstances, buffer 
> bounds checking can be optimized out to produce binaries that 
> are susceptible to buffer overflows.  The article includes a 
> couple examples that really help illustrate the issue -- very 
> interesting reading, IMHO.
> 
> Of course, many/most SC-Lers will no doubt jump on this as 
> another example of why C is such a dangerous language to 
> write (secure) code in, and that's fine.  But, I see the 
> issue at least a little
> differently: a compiler making decisions for the programmer 
> and producing executable code that does not accurately 
> conform to what the programmer coded.  We've all heard of 
> security-related optimizing issues for years, right?  Well, 
> here's a prime example of one in action.
> 
> 
> Cheers,
> 
> Ken
> 
> -----
> Kenneth R. van Wyk
> KRvW Associates, LLC
> http://www.KRvW.com
> 
> 
> 
> 
> 
>