Blunder Dome Sighting  

Hangout for experimental confirmation and demonstration of software, computing, and networking. The exercises don't always work out. The professor is a bumbler and the laboratory assistant is a skanky dufus.

Click for Blog Feed
Blog Feed

Recent Items
Windows Genuine Advantage: So, did I fail the test...
Hark, Is That a Pattern I See Before Me?
NSS2: All Things to All People through Perfect Sof...
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...
Flaws in Genuine Software Still Exploitable in Tru...
A Secure RFID-Identification Protocol?
How Effective Is Your Software QA?
An Entirely New Way of Designing Systems?

This page is powered by Blogger. Isn't yours?

Locations of visitors to this site
visits to Orcmid's Lair pages

The nfoCentrale Blog Conclave
Millennia Antica: The Kiln Sitter's Diary
nfoWorks: Pursuing Harmony
Numbering Peano
Orcmid's Lair
Orcmid's Live Hideout
Prof. von Clueless in the Blunder Dome
Spanner Wingnut's Muddleware Lab (experimental)

nfoCentrale Associated Sites
DMA: The Document Management Alliance
DMware: Document Management Interoperability Exchange
Millennia Antica Pottery
The Miser Project
nfoCentrale: the Anchor Site
nfoWare: Information Processing Technology
nfoWorks: Tools for Document Interoperability
NuovoDoc: Design for Document System Interoperability
ODMA Interoperability Exchange
Orcmid's Lair
TROST: Open-System Trustworthiness



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.

Construction Structure (Hard Hat Area) You are navigating Orcmid's Lair.

template created 2004-06-17-20:01 -0700 (pdt) by orcmid
$$Author: Orcmid $
$$Date: 10-04-30 22:33 $
$$Revision: 21 $