RISKS@KL.SRI.COM (RISKS FORUM, Peter G. Neumann -- Coordinator) (01/26/88)
RISKS-LIST: RISKS-FORUM Digest Monday, 25 January 1988 Volume 6 : Issue 14
FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS
ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator
Contents:
Safe programming languages (Bob Estell)
More about the technology transfer policy (Paul Smee)
A second Sun clock error: no sanity checking (John Bruner)
"Things That Go 'Beep'" (Paul Fuqua)
High-voltages and Europe vs USA (Kee Hinckley)
I know why Ham Radio Operators die so often!!! (silly) (Eric Townsend)
[Sorry -- especially after my comment on the HEADLINE EDITOR -- for an
inadvertent duplication of Alan Wexelblat in RISKS-6.12 and 13. PGN]
The RISKS Forum is moderated. Contributions should be relevant, sound, in good
taste, objective, coherent, concise, nonrepetitious. Diversity is welcome.
Contributions to RISKS@CSL.SRI.COM, Requests to RISKS-Request@CSL.SRI.COM.
> > > > > > > > > PLEASE LIST SUBJECT in SUBJECT: LINE. < < < < < < < < <
For Vol i issue j, FTP SRI.COM, CD STRIPE:<RISKS>, GET RISKS-i.j.
Volume summaries in (i, max j) = (1,46),(2,57),(3,92),(4,97),(5,85).
----------------------------------------------------------------------
Date: 25 Jan 88 07:50:00 PDT
From: "CL351::ESTELL" <estell%cl351.decnet@nwc.arpa>
Subject: Safe programming languages
About a decade ago, Lawrence Flon gave us the following axiom:
"There never has been, nor will there ever be, any programming language
in which it is the least bit difficult to write bad code."
------------------------------
Date: 25 Jan 88 11:41:42 EST
From: John Pershing <PERSHNG@ibm.com>
Re: THE NULL PROGRAM
You can't even necessarily write the null program without encountering
problems...
There is an apocryphal story about the large number of attempts that were
required in order to produce a "correct" version of MVS's null program,
IEFBR14 (this was done back in the days when MVS was still called OS).
As with all MVS programs, IEFBR14 is called using the standard system
calling conventions, and all it has to do is return successfully.
The first version was something like this:
IEFBR14 START
BR 14 Return addr in R14 -- branch at it
END
First bug: A program indicates its successful completion by zeroing
register 15 before returning; this version of the null program "failed"
every time. Try it again:
IEFBR14 START
SR 15,15 Zero out register 15
BR 14 Return addr in R14 -- branch at it
END
Much better. However, this caused some-or-other problems with the linkage
editor, since the END statement didn't specify the primary entry point
of the routine. Version three:
IEFBR14 START
SR 15,15 Zero out register 15
BR 14 Return addr in R14 -- branch at it
END IEFBR14
At least now, the null program was functionally correct. However, dump
analysis was impeded because the program didn't include its own name in
the source code, as an "eyecatcher" (this is a time-honored convention).
Null program, mark four:
IEFBR14 START
USING IEFBR14,15 Establish addressability
BR GO Skip over our name
DC AL1(L'ID) Length of name
ID DC C'IEFBR14' Name itself
DS 0H Force alignment
GO SR 15,15 Zero out register 15
BR 14 Return addr in R14 -- branch at it
END IEFBR14
The next change had something esoteric to do with save-area chaining
conventions -- again, for the sake of conventions and to keep the dump
analysis tools happy.
Note that the "null program" has tripled in size: both in terms of the
number of source statements and in terms of the number of instructions
executed!
-jp
------------------------------
Date: Mon, 25 Jan 88 11:47 GMT
From: Paul Smee <Smee@AUCC.AC.UK>
Subject: More about the technology transfer policy
Perhaps one of the lesser-known 'features' of the US technology transfer policy
is the fact that the US government applies it internationally. For example:
If a British firm manufactures, say, a PC-XT clone, even using 100% British
components (not likely, I'd admit, but for the sake of argument), and then
sells it to one of the proscribed countries, the British manufacturer is deemed
to have violated the US law. This despite the fact that no British law may
have been broken. The manufacturer is now liable to be arrested and prosecuted
if he ever visits the US in the future. Further, in some cases, the US
government will put pressure on the British government which leads the British
government to 'blackball' the manufacturer. Several small UK companies have
been driven under in just this way. Now, according to last week's news
reports, the US is trying to convince the British government to extend the
extradition treaties so that these people could be extradited to the US for
prosecution.
The record of the British government in protecting its nationals in this sort
of case is appalling; typically, they will even refuse to assist in preparation
of an appeal against the US trade restriction. So, I see every reason to fear
that they will give in to this latest idea. And remember, the British
nationals involved can end up in this situation without doing anything illegal
under British law. The attitude of the British government appears to be summed
up as 'well, the Americans are our friends, and we wouldn't want to offend
them'. (Of course, we've got a different outlook on it when the other guys
impose such conditions on their 'friends'.)
There are other side effects of this US legislation. The University of London
had a great deal of trouble getting their second Cray (despite the fact that
they had one). The Cray was already in-country; they were buying it pre-owned
from one of the national laboratories. The problem? The US Department of
Commerce wanted them to sign a statement guaranteeing that only UK and US
national students and staff would be allowed to use it. (I'm not sure what
conclusion was finally reached, but they did eventually get the machine.) More
recently, DEC pulled out of negotiations for selling a mainframe to one of the
Scottish Universities, for similar reasons.
Can this be sensible, I ask myself. Just for clarification, let me add that I
am a US citizen, though resident over here. I think (and hope) that I (still)
have the right to argue against what I see as misguided policies of my
country's government.
The risk? Well, as I see it, a very great risk that in defending us against
the enemy, the government will become as great an oppressor of freedom as (they
say) the other guys are.
Paul Smee, Senior Systems Programmer, University of Bristol
Smee at UK.AC.AUCC via UKACRL.BITNET
at AUCC.AC.UC iff you can find an ARPA host doing domain addressing,
and which does not route thru UCL
pes!bath63!ukc!mcvax!... on USENET (if you're lucky)
------------------------------
Date: Sun, 17 Jan 88 18:53:39 PST
From: John Bruner <jdb@mordor.s1.gov>
Subject: A second Sun clock error: no sanity checking
The recent incident with the Sun leap-year clock problem illustrates
a RISK which noone has mentioned yet: software which blindly trusts
hardware without performing sanity checks on the data received therefrom.
There were two coding errors in the Sun clock code. The first was the
use of a side effect in a macro argument, which caused the hardware
time of day register (TODR) to be loaded with garbage. The second error
was the use of the contents of the TODR without any range checking.
Classically, the time in UNIX has been maintained by software in
response to interrupts from an interrupt source (line clock or
programmable timer). This is true on the Sun as well, except that
every 30 seconds the Sun kernel also compares the software-maintained
time to the contents of the hardware TODR. If the two values differ,
provisions are made to synchronize the software-maintained time to the
hardware TODR. The apparent assumption here is that the TODR will be
more accurate, and usually that assumption is justified.
The system call "settimeofday" changes both the software-maintained time and
the TODR. When the unfortunate leap-year bug manifested itself,
"settimeofday" correctly changed the software-maintained time but trashed
the TODR. Within 30 seconds the kernel detected that the two values were
different and starting trying to "correct" the software-maintained time to
match the garbage in the TODR. A simple range check applied to the
difference between these two values could have detected that the TODR was
trashed and suppressed this "feature."
John Bruner (S-1 Project, Lawrence Livermore National Laboratory)
jdb@mordor.s1.gov (415) 423-4848
------------------------------
Date: Mon, 25 Jan 88 14:57:38 CST
From: Paul Fuqua <pf%ti-csl.csc.ti.com@RELAY.CS.NET>
Subject: "Things That Go 'Beep'"
To add another element to the discussion about risks related to normal
house wiring, the Dallas Morning News on Jan 24 printed an article about an
electric-company experiment in remote meter reading.
Their system broadcasts a "coded electrical signal" at 12500 Hz on top
of the normal 60 Hz power to 5000 customers in the test area. About 1000
participants have a special meter that responds to the signal by reporting
usage or, if so equipped, by turning off major appliances like air
conditioners, water heaters, or furnaces.
The article contains all sorts of glowing comments from the utility
about cost savings and other uses for the equipment (fire alarms, for
example). The focus of the article, though, is on one family that, although
not participating in the experiment, can *hear* the signal as an intermittent
one-second beep, and it's driving them crazy.
RISKS relevance: First, it's a computerised system, and we all know
what hazards there are -- I, for one, don't want my heating and cooling
subject to the utility's direct orders.
Second, around 0.5% of customers in test areas around the country have
complained about the noises. Westinghouse (the manufacturer) is considering
increasing the signal frequency to 19000 Hz. Will it then annoy dogs or
hamsters?
In closing, a quote from the article:
Despite assurances that the signals won't harm electronic equipment, he [John
Feagins, a member of the affected family and a college physics student at UT]
said he wants the signal removed to protect his computer.
"To me, that's like putting something in the water," Feagins said. "I want
pure, clean electricity for all my electronic equipment."
pf
Paul Fuqua, Texas Instruments Computer Science Center, Dallas, Texas
CSNet: pf@csc.ti.com or pf@ti-csl
UUCP: {smu, texsun, im4u, rice}!ti-csl!pf
------------------------------
From: Kee Hinckley <apollo!nazgul@EDDIE.MIT.EDU>
Date: Tue, 12 Jan 88 19:02:46 EST
Subject: High-voltages and Europe vs USA
The European argument is clearly out, not only are most European currents not
DC, most of them are running more than 110. However I have heard concerns
about this recently but I don't remember where. In fact one of the issues
I've read about concerns electric blankets. The article claimed that there
were statistically significant increases in the number of miscarriages from
women who slept under electric blankets. On the level of risk from standard
household current there's an obvious testing problem. Namely it's probably
impossible to find any place where there isn't any current interference and
yet all other factors remain equal. Obviously if you live in a house without
electricity there are bound to be other factors effecting your health. It
seems to me that you'd have to do a very long blind study involving new
houses, some built with heavy shielding, some without.
Kee Hinckley
### {mit-erl,yale,uw-beaver}!apollo!nazgul ### (Apple ][e ProLine BBS) ###
### apollo!nazgul@eddie.mit.edu ### nazgul@pro-angmar.uucp ###
### nazgul@apollo.uucp ### (617) 641-3722 300/1200/2400 ###
------------------------------
From: flatline!erict@uunet.UU.NET (eric townsend)
Subject: I know why Ham Radio Operators die so often!!! (silly)
Date: 11 Jan 88 02:30:55 GMT
Organization: flatline in Houston(Montrose, really), Tx.
It has nothing to do with non-ionizing radiation or with building their
own equipment and the things they get exposed to.
It's very, very simple: Have you ever watched what a Ham Op *eats*????
Yech. :-) :-)
J. Eric Townsend ->uunet!nuchat!flatline!erict smail:511Parker#2,Hstn,Tx,77007
------------------------------
End of RISKS-FORUM Digest
************************
-------