Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…
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. THE VIPER: DEVELOPERS PUSHED BY IMPENDING SENSE OF DANGER - Roger Woolnough ... 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
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, dave@stcns3.stc.oz dave%stcns3.stc.OZ.AU@uunet.UU.NET, ...munnari!stcns3.stc.OZ.AU!dave
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
box.
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.
{ ... }
2. IT IS NOT NECCESSARY TO BOOT FROM A DISK, FOR THAT DISK TO BECOME INFECTED!
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
The following story appears in RESEARCH AND DEVELOPMENT, March 1988, p.41: FLY-BY-WIRE TECHNIQUES ARE BEING ADAPTED FOR AUTOMOBILE CONTROLS 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 maneuverable." 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
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]
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