The Risks Digest

The RISKS Digest

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Volume 6 Issue 48

Wednesday 23 March 1988


o Verified microprocessor for critical applications
Jon Jacky
o Computer rolls give indigestion to voters?
Dave Horsfall
o Re: "NEW" Amiga virus has arrived in Europe
Harv Laser
o "Drive by wire" autos in development
Jonathan Jacky
o The COMMON Code Virus
Kevin Driscoll
o Lazy Lousy Linkers Leave Large Loophole, Let LowLife Lads Loose
Kevin Driscoll
o Info on RISKS (comp.risks)

Verified microprocessor for critical applications

Jon Jacky <>
Tue, 22 Mar 88 09:25:33 PST
The March 14, 1988 ELECTRONIC ENGINEERING TIMES, pps. 54- 60, has a long
story about a British effort to build a completely verified microprocessor
for critical applications.  The story is notable in that it motivates the
effort throughout by calling attention to the possibility of major accidents
involving computer failure.  At the start of the story is a full-page 
illustration depicting a snake with fangs bared, and the lead:

"THE VIPER -- Somewhere - at a nuclear plant, on board a missile, or at a
chemical refinery, it's going to happen: a catastrophic computer-related
disaster.  A growing group of engineers and scientists say it's unavoidable
with today's microprocessors, which they deem inherently unreliable.
Prompted by sense of urgency, they have developed a high-integrity 
processor called ... The Viper.


... John Cullyer, John Kershaw and Clive Pygott of the Royal Signals &
Radar Establishment (RSRE) Computing Division ... make up the team that
has designed the Viper 32-bit microprocessor.  Viper - which takes its name
from "verifiable integrated processor for enhanced reliability" - is the
world's first microprocessor for safety-critical applications.  It's designed
using formal methods and subjected to a lengthy process of formal proof.

... The road that lead to Viper stretches back almost nine years, but the
work began with software rather than hardware.  In the summer of 1979,
Cullyer and his colleagues believed they could firm up the analysis of 
computer programs to detect deeply buried mistakes.  ... By the beginning
of 1983, (they) had applied (static-code analysis) to the examination of 
a number of real military projects. "Put quite simply, we got quite a 
shock," said Cullyer.  "We were very surprised at the mistakes which were
left in software delivered to the British Ministry of Defence.  What also
came out was the fact that some of the problems were due to the
microprocessor chips themselves - not only conventional processors, but also
special-purpose chips.  We found mistakes in things like the fundamental
arithmetic - in the case of one processor, -1 x -1 = -1."

... But are the shortcomings of commercial microprocessors really so serious?
The RSRE team has no doubts on that score, and the substantial literature
it has produced on high-integrity computing spells out many of the dangers
that lurk in today's chips and software.  Says John Kershaw, "It is
questionable whether any computer in general use has ever been fully
specified, in the sense of allowing its response to every possible
combination of inputs and instructions to be predicted.  It is beyond
question that none has ever been fully tested; an exhaustive test of even 
the simplest microprocessor would take billions of years."

(Then followed a lot of material familiar to RISKS readers, but some 
unfamiliar (to me) reports of computer-related accidents:)

...At least one death has apparently been caused by a fault in a computer
program controlling a hospital drug-dispensing machine. ...There are 
two claims for compensation currently going through the US legal system, one
by the widow of a pilot who crashed in an F-16 and the other by the widower
of a patient killed by a faulty intravenous drip machine ...

(A sidebar tells the story of how Viper was verified, using the specification
language LCF-LSM, invented at the University of Cambridge (England) by
Michael Gordon, and a hardware description language called Ella, developed 
at RSRE)

... John Cullyer carried out a proof by hand to show informally that the
major state machine did correspond to the top-level specification, but the
formal proof was a much more extensive exercise.  This was undertaken by
Avra Cohn (of Cambridge).  Cohn's work relied heavily on an automated
theorem prover, and is one of the largest automated proofs ever undertaken.
It took well over a year, and involved more than 1 million primitive
inferences. ... Viper is a simple device from necessity, because a more 
complex architecture would have demanded proofs that are beyond the current
state of the art.

- Jonathan Jacky, University of Washington 

Computer rolls give indigestion to voters?

Dave Horsfall <munnari!!dave@uunet.UU.NET>
Tue, 22 Mar 88 09:52:49 est
Heard on the news this morning, in the wake of the NSW State election, that
a "computer error" caused a number of voters in the Bligh electorate being
registered to vote in the adjoining McKell electorate instead.  The Bligh
electorate was a hotly contested one, with an independant candidate tipped
to unseat the incumbent.

(Note for non-Aussie readers - Aussie elections are still done manually, with
ticks or numbers placed on a page, but electorate rolls come from a database.
I get the giggles whenever I read about those American contraptions!)

Dave Horsfall, Alcatel-STC Australia,, ...munnari!!dave

Re: "NEW" Amiga virus has arrived in Europe

Harv Laser <>
15 Mar 88 07:20:42 GMT
The following message describes a new virus that has appeared on the
Commodore Amiga.  The important points for Risks readers are:

  1. Like the MacMag virus, this Amiga virus ( the "Byte Bandit virus" )
     has infected commercial disks.

  2. Unlike previous Amiga virus strains, this one is harmful, crashing
     the machine.

I have edited the original some, my edits are noted in braces {}.

Scott Norton   4526P@NAVPGS.BITNET   4526P@NPS.ARPA

    --------------------------Original message-------------------------

Cross posted from the AmigaZone (on PeopleLink) this is one man's
experience with the Byte Bandit virus.  Me, I've never seen the thing
myself, only the SCA variety.  I've got a ring of garlic cloves around
my hard drive for now.....

    --------------------------[begin cross post]------------------------

                                                        February 29, 1987

Just got the Byte Bandit Virus from a commercial disk, straight out of the

This is one nasty virus so I thought I would put up some of the features of
this virus that maybe you don't already know about.

{ ... }

   That is, ANY write enabled disk will become infected as soon as it is
   inserted  into ANY drive.  That's right, just inserting a write enabled
   disk in df1:  will cause that disk to become infected!!!!

3. The virus, once in the computer, will survive a warm boot and will still
   infect disks upon boot up.

4. VCheck1.2 will not detect infected disks.

5. VCheck1.2 will not detect infected computers.

6. If your machine is infected then re-installing an infected disk WILL NOT
   cure it because as soon as it is installed (Healed) it will be RE-INFECTED.
  {"INSTALL" is the AmigaDOS command to write a boot block on a disk - SAN }

7. VirusX will recognize non-standard boot blocks such as the Byte Bandit
   virus BUT NOT ALWAYS. If your machine is already infected and you put an
   infected disk in any drive and that infected disk is write-enabled, VirusX
   will NOT detect it!!! Otherwise VirusX will recognize it as a non-standard
   boot block.

{ ... }

9. There is a very complicated countdown mechanism within the virus that keeps
   track of how a particular disk became infected.
   { ... }

I see this virus as being much more potent and contagious than the SCA virus.
This one was created to be destructive, and can be IF we are not careful.
A program like VirusX 1.01 that will detect non standard boot blocks is
helpful, but not infallible. I usually run my system from a recoverable
ram disk that contains my entire workbench disk. Every thing is assigned
to the ram disk so that I don't need my workbench disk in any drive. I feel
relitively safe so long as I know that my boot disk is clean. VirusX caught
that commercial disk as soon as I inserted it in df1:, I became suspicious
and checked it out. So long as a program can be run from my workbench then
I would feel safe. If it becomes neccessary to boot from another disk then
it would be wise to either know that the boot disk is clean or power down
after using. If you have to write to other disks then always be sure that
they have not become infected.

                                                       March 4, 1988

Here's  some more info on the new Byte Bandit virus.  As I told you before,
I  received this virus on a commercial disk, straight out of the box, direct
from the manufacturer.

Virus caused crashes.

   In  my  last  note I stated that the virus causes the Amiga to crash
within  10  minutes  every  time.  This is not quite true.  A newly infected
machine  will  NOT crash period.  (as far as I can tell.  Future generations
of  the  self  replicated  virus  as  it  is passed onto other disks may act
differently)  From  the tests I have performed with this virus it would seem
that  an  infected  machine  will  not  crash UNTIL the virus has replicated
itself  TWICE  by  FIRST DEGREE INFECTION.(I call first degree infection the
infection  of  another  disk  by  re-booting  an  infected  machine  with  a
write-enabled  boot  disk.  The boot disk receives a first degree infection)
After  the  second  disk  has been infected the machine will run for about 5
minutes  30  seconds  before  crashing  with  a  solid  blue screen.  I have
reproduced this effect many times with different generations of the virus.

   The  virus  may  be passed on many times by second degree infection,
without  any  effect  on  the source computer.  Second degree infection is
infection  by inserting ANY WRITE-ENABLED DISK into ANY DRIVE of an infected
machine  WHILE it is already running.  The inserted disk will receive second
degree infection.

{ ... }

Dave Crane

"Drive by wire" autos in development <Jonathan Jacky>
Wed, 23 Mar 88 08:38:38 PST
The following story appears in RESEARCH AND DEVELOPMENT, March 1988, p.41:

by Irwin Stambler

"Fly-by-wire techniques, where electrical signals rather than mechanical
linkages or hydraulic components are used to actuate controls in airplanes,
are finding a new area of application - automobiles.

One of the latest advances in this area is a sophisticaed steer-by-wire
algorithm devised by researchers at Univ. of Southern California, Los
Angeles, that is being tested in an experimental computerized car built
by General Motors Corp., Detroit, MI.

Dr. Petrous Ioannou, of USC's School of Engineering, said that the use of
a variety of drive-by-wire systems in automobiles is nearer at hand than
most people think.

'Recently BMW in West Germany introduced a V-12 drive-by-wire automobile.
Now that one company has replaced hydraulic components with electrical
ones, the door may be open for many others to follow suit,' he told R&D.

The use of computer-controlled steer-by-wire systems offers a number of
advantages. "The result would be a car that's significantly lighter...",
he said. "A steer-by-wire system would be considerably more responsive and

Ioannou and a team of graduate students are in the third year of a five-
year program funded by the National Science Foundation to develop automotive
control algorithms.  The first part of the work involved computer
simulation, and the researchers are now collecting data on how the algorithm
works in the GM test car.

"That car contains and electrical motor connected to a computer which, in
turn, receives signals from the steering column. ..." The USC algorithm
measures the velocity and and position of a steering section pinion.
"Data are examined and the algorithm determines a voltage instruction to the
computer to insure that the output of the motor follows a certain pattern.
The computer then calculates the forces required to insure [sic] that
commands are properly carried out."

One important requirement in this application is that the system responds
rapidly in situations where a driver needs to perform a sudden maneuver,
such as to avoid a collision.  "For a sudden turn, the algorithm must be able
to determine the required electrical outputs extremely fast, and the system
must respond very quickly as well."

"We plan to get into braking and other control functions.  We don't see this
as involving any radical change from what we already have," Ioannou said.

(end of excerpts)

This article reminded me of a discussion of the possibility of drive-by-wire 
in RISKS about a year ago.  As I recall, many people pointed out that
fly-by-wire aircraft cost on the order of 1000 times as much as autos, and
are subject to much more intensive maintenance.  By the way, can anyone 
confirm Ioannou's statement that BMW has a drive-by-wire car on the market?

Jonathan Jacky, University of Washington

The COMMON Code Virus

Kevin Driscoll <umn-cs!srcsip!>
Sun, 20 Mar 88 13:17:30 CST
In Risk Digest 6.46 Ewan Tempero writes:
<>> What was interesting about this was that problems occurred in May 1986.  I
<>> had no idea that the computer virus had been around that long nor that it

My first encounter with a computer virus (definition:  a software parasite that
replicates itself to a new location) was a quarter of a century ago.  I assume
that the basic concept is even older.  This virus was the first of the COMMON
code abuses that I wrote about earlier.  The virus was the single instruction:
        MOVE (Program Counter) --> Program Counter + 1
It had the effect of copying itself to the next memory location, which was
then executed . . .  At the top of memory, the Program Counter rolled over to
zero.  Thus, in a matter of milliseconds, the entire memory contained just
copies of this instruction (no memory protection in those days).  This had an
interesting symptom on the control panel.  The normal random-like pattern of
the address lights became the distinct binary counter pattern.  Because every
memory cell was overwritten by this process, it left no clues about its origin.
(Was this the first single cell computer virus?)
    Like any virus, the computer virus needs population contact in order to
spread.  "In the old days", computers were relatively isolated so viruses were
contained to single computer sites.  Today, with networks, bulletin boards,
and the wide spread sharing of storage media, the spread of viruses has become
a major problem.
   The concept of a "clean room" for computers may have to take on a software
as well as a hardware meaning.
                COMPUTER ROOM
                  No Smoking
                   No Food
                  No External Media

   [And there is no cure for the COMMON code.  PGN]

Lazy Lousy Linkers Leave Large Loophole, Let LowLife Lads Loose

Kevin Driscoll <umn-cs!srcsip!>
Sat, 19 Mar 88 11:00:19 CST
The recent discussion of linkers reminded me of the following:
   In the mid 1960s the university in my home town had an IBM 360 that was
used for both administration and student programming courses.  Realizing the
potentional problems, the administration restricted the student access to
punched card Fortran programs.  Once an hour, all the student decks were run
through a batch compile-and-execute which made sure that these programs did
not do anything unsafe.  This scheme was bypasssed with:
      COMMON /IT/I(1000)
      (fill array I with the integer equivalent of nefarious machine code)
      CALL IT
The compiler made IT an external symbol when it saw the COMMON statement.  The
compiler then saw that IT was an external symbol in the CALL statement; so it
left the resolution to the linker.  The linker, not having any type checking,
simply put the COMMON address in as the target of the CALL.  After getting the
operating system's microfiche documentation, the students could make the code in
COMMON a starting point for anything they wanted to do.
(Nothing made the system more sick than the COMMON code.)

On the subject of pilots' reliance on avionics computers -- some pilots, in
addition to relying on computers to give them information on the current
situation, also seem to use the computers as a replacement for their memory.
     "What altitude are we supposed to be flying at?"
     "I dunno, check the computer."
This was not the originally intended, nor currently sanctioned, use for this
equipment.  But, if this is the way it is sometimes used, does this equipment
have to be built with the increased reliability needed for this unsanction use?

Please report problems with the web pages to the maintainer