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: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] 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 > > > > > > _______________________________________________ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. _______________________________________________
