[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Can a machine test itself? + other issues
I am being highly practical. But based on the myriad of reports
flooding in about the last election, it is becoming more clear to me
that integrity, reliability, and security of voting systems has indeed
gone down the drain.
These systems are permitted by the existing standards (and by the latest
P1583 draft as well) to be no better than shoddy and seriously
unreliable, and they perform accordingly.
On Wed, 2004-12-08 at 12:13, Dick Johnson wrote:
> You raise some interesting theoretical issues, but my sense of it is
> that you have passed the bounds of the practical. The economic basis of
> computers was and is that they may run more than one program. It does
> not have to be this way; you could design and build a dedicated,
> one-purpose machine with hardware and software all custom crafted.
> Quite expensive, really, since all development costs must be amortized
> over one specialized application. The profit potential is limited,
> given the costs of development, so no private party would want to do
> this. Are you sure that the political realities are such that the U.S.
> Government in a time of deficit would choose to spend money on elections
> rather than tax cuts? I might agree with you on the desired approach to
> election equipment, but I am not very influential regarding the federal
> government's spending plans.
> The fact of the matter is that in the real world we have MS Windows and
> Linux from which to choose, generic PC firmware and hardware,
> specialized and general purpose printers, proprietary hardware, and
> either open source or proprietary specialized voting software. From
> this mix, all US voting systems will certainly emerge. We do have the
> option of specifiying Open Test to supplement the existing proprietary,
> private, and inscrutible test organizations currently providing
> certification. Our standards must provide a measure of how well an
> individual voting system is likely to function, given our understood
> Otherwise, although interesting, speculation about total custom voting
> systems (Open Source and Open Hardware Designs?) does not seem helpful
> except in order to highlight what is needed in the real world.
> This is my personal and professional opinion, and it does not
> necessarily reflect the opinions of my employer.
> -- Dick
> Richard C. Johnson, Ph.D.
> Applications Architect
> Oracle Corporation
> Stanley A. Klein wrote:
> >"BIOS" is just the acronym for the name IBM chose around 1980 for their
> >firmware interface when they built the PC.
> >The issue you seem to raise relates to the presence of an "operating
> >system" that is a general program providing services and control to
> >application programs. In your embedded systems, the operating system is
> >likely to be a stripped-down program more tightly coupled, as you say,
> >to the applications.
> >The issue is one of generality versus tailoring. Generality puts stuff
> >in the firmware interface and the operating system that isn't needed by
> >every application. A voting system (or a pacemaker, for that matter)
> >isn't also going to be used to word process business letters. And all
> >that extra stuff that isn't needed for what the system actually does is
> >a source of concerns for integrity, safety, and reliability.
> >The bottom line is that it is cheaper to throw in the kitchen sink, even
> >if you don't need it, but if you do your integrity, safety, and
> >reliability may go down the drain.
> >Stan Klein
> >On Tue, 2004-12-07 at 22:38, Vincent J. Lipsio wrote:
> >>>Every computer system needs some kind of firmware to interface the
> >>>operating system to the physical hardware. The BIOS just happens to be
> >>>the PC name for that function.
> >>Point well taken. However, my perception is that the use of the term "BIOS"
> >>suggests an assumption that the system is, in fact, a PC, and not hardware
> >>designed for the purpose, with consequent presence of all sorts of stuff not
> >>related to voting, both hardware and software, and, therefore, many more
> >>chances for hidden problems. I am accustomed to designing systems with
> >>absolutely no unused components, hardware or software, to reduce the cost
> >>of validation and minimize the risk of some wayward component adversely
> >>affecting the system.
> >>Also, the bootstrap and ROM monitor (which, i believe, is what a PC's BIOS
> >>is) are now often linked with the application code on embedded systems.
> >>And, a BIOS is generally perceived as a black box that can be substituted
> >>with any other BIOS designed for the same generation of hardware; hence, this
> >>thread's original author's comment, "I have been inquiring about a foolproof
> >>way to verify a BIOS. I'm not sure that one exists."
> >>Vince Lipsio
> >>Every program has at least one bug and can be shortened by at least one
> >>instruction -- from which, by induction, one can deduce that every
> >>program can be reduced to one instruction which doesn't work.
Stanley A. Klein <firstname.lastname@example.org>