Re: Proverbial appliance "Its software, Jim!"

[wolt () igd fhg de (Stephen D. B. Wolthusen)]

Hi,

Mike Frantzen <frantzen () w4g org> writes:

> There are two applicable difference between a hardware firewall and a
> software firewall.  In hardware, everything happens in parrallel (well,
> every stage, you'll latch between stages to produce a sequential
> pipeline).  And the other difference, is that hardware testing standards
> are orders of magnitude better than software testing standards.
>
> The first person who tells me VHDL or Verilog is software gets labeled
> a dumbass.

Then call me dumb***, but I've been called worse. Your argumentation is a
bit disingenuous. An ASIC is a piece of software where I have to consider
some additional constraints for signal pathways and
suchlike. Fundamentally, there's nothing different from ``soft'' software,
except for a few more things that can go wrong. 

Hardware developers traditionally have a higher standard for design,
development, and testing methods than the software crowd. Mainly because
even bean counters can understand that fixing bugs downstream in
custom/full custom design is hideously expensive. Reprogrammable
architectures, microcode patches etc. may well erode this barrier to sloppy
work.

To quote Mike Feldman, the motto of the software industry is ``We never
have time to do it right, but we always have time to do it over.'' Always
has been, still is.

> > It
> > doesn't matter if you're design tool is back-of-the-envelope or the best
> > that Rational has to offer.  You're still human and fallible.

That's why you try to eliminate the human factor as much as possible. 

Use formal methods for your design and specification. Fancy UML diagrams
still leave enough ambiguity to be mostly a feel-good exercise. 

Refine this as far down to actual code as you can afford (getting
``executable'' FM specifications is frequently too expensive both in terms
of computational efficiency and actual monetary cost), in some cases such
as control systems for weapons systems and avionics, it can be justified to
go to the level of program proofs (with tools such as Z/EVES or the SPARK
suite, that can be managed).

Depending on the level of rigor with which formal methods are used, defect
rate reductions have been reported in case studies ranging from 5x to
around 100x. 

Use a programming language that assists the programmer, and doesn't permit
him to overwrite arbitrary storage six ways from Sunday. Plus, use a
language that is well-defined in its syntax and semantics (Hint: neither C
nor C++ nor Java nor... is). 

For Ada 95 it is hard to get compilers that have not been evaluated for
conformance to the ISO standard with a torture test suite; the rigid
semantics were one of the reasons why it was chosen as a basis for VHDL. In
case of C/C++ I can't even be sure what the semantics of an operation is.

Again, case studies have shown that all else being equal, Ada programs have
a defect rate about 10x lower than C, so it's *not* just a matter of a
different syntax as some people are likely to claim.


Now an exercise for the reader: How many projects (OK, anyone who uses
``DO-178B'' and similar acronyms in conversation won't count) you know of
use formal methods for design and specification and derive their code by
rigorous correspondence argument or proof in a language with well-defined
semantics.

OK, that was my rant for this month. 

-- 
        later,
        Stephen

Fraunhofer-IGD                 | mailto:
Stephen Wolthusen              | wolt () igd fhg de
Fraunhoferstr. 5               | swolthusen () acm org
64283 Darmstadt                | swolthusen () ieee org
GERMANY                        | stephen () wolthusen com
                               | 
Tel +49 (0) 6151 155 539       | Fax: +49 (0) 6151 155 499 
    +49 (0) 172 916 9883       |      +49 (0) 6245 905 366 
_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards