Atom Feed

Associated Blogs
 
Edge City
 
Numbering Peano
 
Orcmid's Lair
 
Praxis101
 
Spanner Wingnut's Muddleware Lab

Recent Items
 
Windows Genuine Advantage: So, did I fail the test or did the test fail?
 
Hark, Is That a Pattern I See Before Me?
 
NSS2: All Things to All People through Perfect Software
 
Are You A Problem Witch or a Solution Witch?
 
How Do You Know Your Discarded Disk Is Unreadable?
 
Uh, lemme see, I'm gonna hack my router and expose my residential LAN to the Internet ... Not.
 
Flaws in Genuine Software Still Exploitable in Trusted Environment
 
A Secure RFID-Identification Protocol?
 
How Effective Is Your Software QA?
 
An Entirely New Way of Designing Systems?

Archives
2004-06-13
2004-06-20
2004-06-27
2004-08-29
2004-09-05
2004-09-12
2004-09-19
2004-10-10
2004-10-24
2004-11-07
2004-11-28
2004-12-05
2004-12-12
2004-12-26
2005-01-30
2005-02-06
2005-03-06
2005-03-13
2005-03-20
2005-04-03
2005-04-10
2005-04-17
2005-04-24
2005-05-01
2005-05-08

Three Defects We Can Do Without: Memory Leaks, Buffer Overflows, and Unclosed Files

ACM News Service: Silver Bullets for Little Monsters: Making Software More Trustworthy.  David Larsen and Keith Miller identify available solutions to three defects, suggesting that it is no longer necessary to tolerate these any longer.  Oh, OK: These aren’t infallible, but they can improve the situation dramatically.

A number of tools are mentioned, including Microsoft’s Slam, a C program static analyzer that authenticates the program against rules stated in its Specification Language for Interface Checking.  Now wouldn’t that be just SLIC.

The link to the article in the 2005–04 issue of IEEE IT Professional is directly to an Adobe Acrobat PDF.  (I hate it when that happens. You’ll have to condition your browser and firewall security to get the kind of access you want.  I only crashed my browser once before getting it to work.) You may find it easier to work from the free-article page or the table-of-contents of the publication after the free-download promotion ends.

The abstract resonates for me:

Despite the legions of ideas about how to improve software quality, much commercial software remains un-trustworthy. In this article, the authors make the case for at least taking small steps toward improved quality by using silver bullets “corrective actions or methods” to at least eliminate some common problems, the “little monsters” of the title.

I am left wondering why these particular problems aren’t greatly reduced by disciplined structural constraints on programs, ones that are easy to confirm.  This would make confirmation that memory (and pointers) are released, that buffer-filling code is properly defended, and that resources are released subject to relatively simple inspection and well-crafted dynamic testing.  Edge cases must still be addressed with regard to unexpected data and resource acquisition/retention problems, but I’d think it very worthwhile to combine structural constraints with confirmation techniques.  I’m also wondering what hackers use to discover those defects as prospective avenues for security exploits. 

With that inquiry in mind, I discovered additional gold in the article:

• Trust gradualism: The notion of choosing carefully and eliminating (or seriously reducing) the incidence of a couple of pesky cases with existing silver-enough-bullets
• Tracing of “software trustworthiness” back through David Parnas (1990) to F. Lockwood Morris (1973) and John McCarthy to what seems to be an unsatisfactory conclusion around what constitutes a catastrophic outcome.  I suspect that an affirmative approach may serve us better but I will relish going to the sources that are provided here.
• Simple practices that would go a long way and that have seen little adoption (or are at least kept obscure):
• a minimum standard for software testing
• third-party assessment of software quality
• good-faith negotiation about achieving “good-enough” software
• Reminder that the 10 provisions of Cem Kaner’s August 2003 Software Customer Bill of Rights bear on trustworthiness too, including
• disclosure of know defects
• freedom to make public criticism, publication of benchmark studies, and other statutory fair usage
• and [two more I would add], disclosure of all external communications (with user permission required) and assured access of users to their own data (which means to me that data formats are disclosed or that exporting is assured, and that applies to data for which custody is not on the customer’s system)
• The little monsters approach: “If developers aren’t completely candid about known defects, perhaps they can eliminate particular types of defects and then declare that such defects are absent from their software.”
• Choice of three of the 12 pesky critters that Valdis Berzins says are amenable to promising automated methods, with a stack of references, industry examples, and available products for those three.

This paper is a keeper for students of this subject.  From my perspective on TROSTing, I would say that declaring the absence of any sort of defect is problematic (as Knuth has famously remarked, and Edsger Dijkstra seemed to begrudge the point as well).  It strikes me that it is more appropriate to assert diligence in application of current art, specifying which measures were applied to mitigate the prospect of various understood defects, and certifying that.  Declaring perfection strikes me as foolhardy, especially since the user who stumbles on a defect will not care which category it falls in, if any.  Demonstrating diligence I can see as do-able at the current level of art.