On 04/10/2014 04:02 PM, Rahul Sundaram wrote: > Hi > > > On Thu, Apr 10, 2014 at 3:19 AM, Ian Malone wrote: > > . > This bug was pretty bad, but the kind of mistakes that lead to > overflows and over-reads tend to be from not keeping track of the data > properly and will cause other problems anyway, memory protection > doesn't help with those. > > > In a managed language, it isn't typically possible to read past the > end of an array without it resulting in obvious errors. So while it > isn't a silver bullet, it could have helped significantly here to > notice the problem and correct the relevant related code. > Unfortunately C continues to dominate as a popular systems programming > language and these types of errors remain a frequent problem largely > because language level support for higher level abstractions remain > extremely weak. The fact that a major piece of extremely security > critical code received almost no support from commercial vendors for a > detailed audit for security flaws also remains a problem. > The cost of a "managed language" is that it affects performance. There are essentially 2 phases in language. The first is static. The language is compiled, and the compiler attempts to prevent buffer overflows or reading past the end of an array. FORTRAN has had this for over 50 years. The second is dynamic or during run time. Some languages have this (mostly interpretive languages). There is code that exists for C that also can prevent this. But, OpenSSL, and libc, and other run-time libraries on Linux and Unix and even DLLs in that other OS need to consider performance, or the lack of. But, I maintain that virtually any language suitable for use in run-time libraries can be subverted. But if we go lower, there are even bugs in the chips. Remember the Intel floating point bug a few years ago. But, since our underlying libraries are written in C and are going to be that way for a bunch of years, we should start using, or mandating the use of tools such as Valgrind and Rational Purify as a method of testing the code. These help the programmer locate potential latent bugs. Not sure about Valgrind, but Purify takes libraries into account. -- Jerry Feldman <gaf@xxxxxxx> Boston Linux and Unix PGP key id:3BC1EB90 PGP Key fingerprint: 49E2 C52A FC5A A31F 8D66 C0AF 7CEA 30FC 3BC1 EB90
Attachment:
signature.asc
Description: OpenPGP digital signature
-- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
