Thou shalt have no other gods before the ANSI C standard 1599

David Wagner

Even if errant reads are a real problem, focusing on errant writes is probably not a mistake.

I failed to mention that the NCHECK code should be written by someone other than the author of the non-NCHECK code. This technique is decades old, and is a far more useful technique than the eXtreme Programming paradigm of writing the tests first. Making the code evaluate itself yields a more effective coverage metric.

snip

There is room for further discussion here. The topic would be absolute value versus relaive value. The phrase "good enough" suggest that there is an absolute value or critera that should be applied. That path leads to the hopless goal of perfect software.

The alternative or relative or incremental value, such as disciplined methodolgy or automated error checks is easier to envision, but does not guarantee "enough" improvement to materially reduce the icidenc the of exploits. After all, any given progam needs only one serious vulnerability, so finding all but the last one does not increase the effective security of the system. Also, along this path lies hype because we still lack a metric for (in)security.

For me this is depends on the day of the year. On even days I'm an absolutist, and on odd days a relativist. On Feb 29ths I curse Babbage, Turing, and Djikstra. ;-)

The cost of that in complexity and performance is extremely high. Would you write any of these in a memory-safe language? - a file system - heap manager - swap manager - page fault handler - garbage collector - device driver (e.g., SCSI-3 or ATi Rage Pro) - network driver - network stack - network firewall - or debugger

OK I accept your opinion. Are there any other kinds of defects that have that property?

Your list is sufficient to trigger something like an "Aha!". Consider that in any executable the examples you gave are examples of non-application-accesible addresses. We can color them red. The set of program-declared and system-supplied variables are the blue adresses. In theory programs have access only to blue addresses. But proving that a program stays within the blue zone is very difficult. Part of the difficulty lies in the intermediate grey addresses which might or might not be appropriate based on context.

The set of red locations can be increase by adding to your list. But the key observation is that there is a set of addresses that no application code should ever touch. That makes the analysis conxext-free (in some sense). Ihe individual subsets of those red addresses can be built on a system-by system or program-by-program basis, mostly automatically (using the linker and a .map post processor).

Add to the above a form of automated analysis similar to interval arithmetic as applied to program variables and you have the possibility of a tool that could warn of constructs that have the potential of interacting with red addresses.

I'd be interested in working on such a tool. It would be terribly slow, but you only have to run it once per module, component, or subsystem. So it it takes an hour or a day to run who cares?

I think such a tool is within the current state of the art. If it existed, would it be useful enough to spend the time to run it and interpret the results (a list of software that has the capacity to write to red addresses)?

tj3